2

I've just tried to SSH in to a server that I've been doing so without problems for a while, and received a warning that the server's host key has changed.

But it hasn't!

On the server, I've checked the hosts key which is being referenced in /etc/ssh/sshd_config, and it has not changed.

On the client, I checked the known_hosts file, and the existing entry in there has the correct public key. I tried moving the known_hosts file away temporarily, and set StrictHostKeyChecking to no in /etc/ssh/ssh_config so that it would automatically connect so I could compare the public key. When I did this, and checked the new entry in known_hosts, the public key part is identical to before!

So why wouldn't it connect? The only thing that is different in known_hosts is the salt and hash of the hostname. But since I am, and always have, connected via the IP and port, without using the hostname, these must surely be correct.

Any ideas?

Note that all clients attempting to connect that have previously connected are getting this message. So it's not a problem with the client.

EDIT: I should add that when I connected with StrictHostKeyChecking set to no and it created a new known_hosts file, when I then tried connecting again using the new known_hosts file and StrictHostKeyChecking back to yes, it connected without warning. In other words, the new known_hosts file worked without warning, whereas the old one did not, despite having the same public key inside.

melkamo
  • 213
  • 1
  • 2
  • 6
  • 3
    There's definitely no MITM?? – Alex Leach Apr 13 '12 at 00:30
  • 2
    Those checks are in place for a reason... If you entered your password onto the server after it failed host checking, I'd change your password quickly... – Alex Leach Apr 13 '12 at 00:33
  • Not definitely but if there was MITM, when I disabled host checking to test, wouldn't it have added a different public key to the known_hosts file? That's what's got me stumped - it's adding the same key. – melkamo Apr 13 '12 at 00:36
  • 1
    The message about the mismatched host entry should have told you which entry was in conflict. – David Schwartz Apr 13 '12 at 01:22
  • @David: Yes, it did, it said the key itself did not match. As a test on the same client, I changed the hostname hash, and it gave a different message mentioning that the host did not match. Therefore, the error I received was specific to the public key section. Yet, the public keys matched. I just don't get it. – melkamo Apr 13 '12 at 02:38
  • @melkamo: I strongly suggest you inform yourself about the so-called ["Man In The Middle" (or MITM)](http://en.wikipedia.org/wiki/Man-in-the-middle_attack) attack. – Steven Monday Apr 13 '12 at 02:55
  • @StevenMonday: I'm well aware of what MITM attacks are. I thought I'd made it clear that I know the public key, and have been able to verify it. This rules out MITM, no? – melkamo Apr 13 '12 at 03:01
  • @melkamo: I would not rule it out, no. You stated that "all clients attempting to connect that have previously connected are getting this message". Please update your question with the exact text of this message, as I am now very curious to see it. – Steven Monday Apr 13 '12 at 04:43

1 Answers1

4

You shouldn't disable host-key checking at all for this test.. When the error message pops up about a conflict, it prints the fingerprint and as David says, tells you which entry is mismatched in the known_hosts file.

You can compare the fingerprint with the host key; I don't know off-hand, but an internet search will tell you.

Something like ssh-keygen -l -f server-public-key.txt [linuxforms] would do it.

Also, using ssh -vv and checking /var/log/auth.log (or equivalent) should tell you more about the issue

Alex Leach
  • 1,697
  • 3
  • 16
  • 18