0

I have an issue with connecting to my ssh hosts. I keep getting this message in verbose mode:

OpenSSH_7.2p2, LibreSSL 2.4.1
debug1: Reading configuration data /Users/me/.ssh/config
debug1: /Users/me/.ssh/config line 4: Applying options for *.ta.local
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to <host_name> [<host_ip>] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/me/.ssh/id_ed25519 type 4
debug1: key_load_public: No such file or directory
debug1: identity file /Users/me/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to >host_ip>:22 as 'me'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:+Wl92PcQ6xQSAtNdxvAeBWExxDXl6NM0M4i6dUEvVA0
The authenticity of host '<host_name> (<host_ip>)' can't be established.
ECDSA key fingerprint is SHA256:+Wl92PcQ6xQSAtNdxvAeBWExxDXl6NM0M4i6dUEvVA0.
Are you sure you want to continue connecting (yes/no)?
Host key verification failed.

FYI: in the pasted trace, I replaced username, host and ip...just in case someone is confused.

Here is my ssh_config:

Host *
    SendEnv LANG LC_*

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Protocol 2
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
#   RekeyLimit 1G 1h

I read a lot about that the host key may have changed since my last login. So I already tried removing the entries in the known_hosts file and still keep getting that error no matter what ssh server.

Any idea what I might got wrong here?

Further information: I recently updated mac os to sierra. Maybe it is related.

Improve this question
2
  • Is it an automated process that is trying to connect via SSH or are you doing it yourself?
    – mzhaase
    Oct 10, 2016 at 11:13
  • I was doing it myself. Just solved the problem by passing StrictHostKeyChecking=no
    – Igl3
    Oct 10, 2016 at 13:09

1 Answer 1

Reset to default
1

As you may know, fingerprint changing can mean that you are being under a man in the middle attack, so take that in mind firstly.
From What is a SSH key fingerprint and how is it generated?:

The fingerprint is based on the Host's Public key, usually based on "/etc/ssh/ssh_host_rsa_key.pub" Generally its for easy identification/verification of the host you are connecting to.

If the fingerprint changes, the machine you are connecting to has changed their public key. This may not be a bad thing(happens from re-installing ssh), but it could also indicate that you are connecting to a different machine at the same domain/IP(happens when you are connecting through something like load balancer) or that you are being targeted with a man-in-the-middle attack, where the attacker is somehow intercepting/rerouting your ssh connection to connect to a different host which could be snooping your user/pw.

So, if you are now sure that the server is secure, I'd suggest connecting manually and acepting the new fingerprint as it seems to be the easiest solution to your problem.

Improve this answer
2
  • 1
    Thank you for the advice, that this is a common sign for a man in the middle attack. I can rule this one out, it is probably due to an attempt to create a self signed certificate earlier this week, that might have messed up something with my keys. As in the comment above, I solved it by disabling the host key check once. I gonna close the question, as it is not very useful for others, as my issue was self inflicted and kinda special. Anyhow, I gave you an upvote for explaining the mitm thing.
    – Igl3
    Oct 10, 2016 at 13:12
  • Okay, I can't close it after receiving an answer and there is no matching option for flagging it as closable. So, I let it as is, and accept your answer.
    – Igl3
    Oct 10, 2016 at 13:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .