Don't works without asking for password, even so it works when using just 'ssh' command

[gleisonsilva]

I couldn't figure out how to connect to a remote host without typing the password. My SSH is already configured to connect that way, but with spire it doesn't works.

---

Using Spire:
~ spire -e '(ssh {:host-string "root@s0828" :identity "/Users/gleison/.ssh/id_rsa"} (get-fact))'
Enter Password for root@s0828:

(I've tried using :private-key also, but the behavior is the same. Already 'cat' the file to make sure it exists and have the expected content... and it doesn't have a passphrase)

---

Using SSH:

~ ssh root@s0828
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Mar 18 19:28:16 2020 from 25.32.92.157
root@ServerB:~#

[retrogradeorbit]

That ssh command you are comparing with may be using other authentication mechanisms as a fallback. Can you try ssh -i /Users/gleison/.ssh/id_rsa root@s0828 and tell me if that works? I will be adding a connection debug option to assist in tracking down connection problems like these for the next release.

[gleisonsilva]

Hi! Tks for your reply. I did the test, but the result (using -i ... in ssh) was the same. Nothing new to report.

[retrogradeorbit]

New release soon which will enable you to debug this connection. I would recommend using an ssh-agent for the time being as a work around.

[retrogradeorbit]

The new version of spire 0.1.0-alpha.3 contains a --debug-ssh command line option. Can you try this on your failing :identity example when you get a chance?

[gleisonsilva]

The new version of spire 0.1.0-alpha.3 contains a --debug-ssh command line option. Can you try this on your failing :identity example when you get a chance?

Hi!

I've try using this new option and the output is here:

$  spire --debug-ssh -e '(ssh {:host-string "root@s0828" :identity "/Users/gleison/.ssh/id_rsa"} (get-fact))'
Connecting to s0828 port 22
Connection established
Remote version string: SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u7
Local version string: SSH-2.0-JSCH-0.1.54
CheckCiphers: aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc,aes192-cbc,aes128-cbc,3des-ctr,arcfour,arcfour128,arcfour256
CheckKexes: diffie-hellman-group14-sha1,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
CheckSignatures: ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
ecdsa-sha2-nistp256 is not available.
ecdsa-sha2-nistp384 is not available.
ecdsa-sha2-nistp521 is not available.
SSH_MSG_KEXINIT sent
SSH_MSG_KEXINIT received
kex: server: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
kex: server: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
kex: server: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
kex: server: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
kex: server: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
kex: server: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
kex: server: none,zlib@openssh.com
kex: server: none,zlib@openssh.com
kex: server: 
kex: server: 
kex: client: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
kex: client: ssh-rsa,ssh-dss
kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
kex: client: aes128-ctr,aes128-cbc,3des-ctr,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
kex: client: hmac-md5,hmac-sha1,hmac-sha2-256,hmac-sha1-96,hmac-md5-96
kex: client: none
kex: client: none
kex: client: 
kex: client: 
kex: server->client aes128-ctr hmac-sha1 none
kex: client->server aes128-ctr hmac-sha1 none
SSH_MSG_KEX_ECDH_INIT sent
expecting SSH_MSG_KEX_ECDH_REPLY
ssh_rsa_verify: signature true
Host 's0828' is known and matches the RSA host key
SSH_MSG_NEWKEYS sent
SSH_MSG_NEWKEYS received
SSH_MSG_SERVICE_REQUEST sent
SSH_MSG_SERVICE_ACCEPT received
Authentications that can continue: publickey,keyboard-interactive,password
Next authentication method: publickey
Authentications that can continue: password
Next authentication method: password
Enter Password for root@s0828:

You can see that it still asks for password.

Rgs

[tomconnors]

I'm having SSH issues as well. @retrogradeorbit explained this workaround that fixed the problem for me:

• check you are running an ssh agent with ssh-add -l
• then if your key is not already added, add it with ssh-add path/to/key
• then try spire just specifying username and hostname and see if that connects

I am also able to repro the issue (without a running ssh agent) reliably with these steps:

• Create a new Ubuntu 20.04 (lts) server
  I'm using AWS for this. I assume the important part is the sshd config, reproduced here, and unmodified from its original state:

#	$OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

Include /etc/ssh/sshd_config.d/*.conf

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile	.ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem	sftp	/usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server

• Use a new key pair generated by AWS. It's a passphraseless RSA key.
• chmod 0600 /path/to/keypair.pem
• Verify you can ssh in with ssh -i /path/to/keypair.pem ubuntu@ipaddress
• Attempt to connect with spire, using spire test.clj and a test.clj containing:

(ssh {:username "ubuntu"
      :hostname "ipaddress"
      :identity "/path/to/keypair.pem"
      }
     (get-fact))

LMK if there's more info I can provide to help w/ reproducing this.

[jrasanen]

Same here, can reproduce by spinning up a new server, then trying to ssh to it using Spire.

Server with all the default values and up-to-date packages,

root@primary:~# lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.4 LTS
Release:	18.04
Codename:	bionic

I can ssh to it without any problems, but using spire it asks for a password even when identity file is provided.

[retrogradeorbit]

could be an issue with pem encoded identity files. #48

[retrogradeorbit]

OK. trying to replicate this on AWS with a downloaded PEM key. Could connect with the pem in :identity, but only when os environ SSH_AUTH_SOCK was not set . I think this is what is being experienced here. A lot of users have an ssh agent set up by default on the OS, but they aren't using it. see ticket #49

Running export -n SSH_AUTH_SOCK before running is another workaround

[retrogradeorbit]

This should be fixed in 0.1.0-alpha.9. reopen if there are still problems.