Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
There's definitely no MITM?? – Alex Leach Apr 13 '12 at 0:30
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 0: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 0:36
The message about the mismatched host entry should have told you which entry was in conflict. – David Schwartz Apr 13 '12 at 1: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 2:38

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

share|improve this answer
/etc/ssh/ in ubuntu and most debian systems. – isaaclw May 30 '13 at 18:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.