Super User is a question and answer site for computer enthusiasts and power users. 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'm receiving the wonderful "The authenticity of host xx can't be established." message when attempting to SSH into a box. I have two systems that recently swapped names. My system is a RHEL5.6 box.

System X with IP xx
System Y with IP yy
Changed to System X with IP yy, system Y with IP xx.
(hope that's easy enough to explain what we did)

I removed both systems from my .ssh/known_hosts file (and verified neither IP is listed anywhere), but when I SSH into one of them, it still shows the IP of the original name. The other system works no problem, but it appears that there is a cache somewhere that still has the old information.

I've completely cleared the known_hosts file, as well as rebooted the system, in an attempt to clear the problem, but with no luck.

Any ideas? I'm stumped! This is only happening on my system, nobody else has a problem.

Update: I had already removed the offending keys from the file. I had also completely erased the known_hosts file. It still happens. there is nothing different in the configuration of the .ssh than any other account. And if it was an error in the .ssh files, it would affect other ssh connections as well. But the other system that had swapped names with this one, does NOT give this problem. it works correctly. It is only one of the two systems having the problem. The box has been reloaded twice since this change as well. So I know it's not the server itself.

I found out that my coworker is also having the same issue now, with the same box. And only this one box.

So if our DNS zone files are correct, where could this possibly be coming from? Neither system involved in this change has the old information in it. our DNS looks clean. Our accounts do not reference the old info. tracert shows the old IP with the name, as does ping, and then ssh. But an nslookup using forward or reverse comes back correct. Kinda frustrating.

share|improve this question
Could you post the exact error message? There are more locations than just ~/.ssh/known_hosts. It could be DNS, or /etc/ssh/ssh_known_hosts. – grawity Apr 6 '11 at 11:42
The offending keys are removed. The problem is that the IP address that shows with the host name when asking you to accept the connection (after the key is removed) is the old IP address. It is not the new one. Something is caching the old IP information. So when I select yes to connect, it connects to the old IP, which is the system it swapped names with. This only happens to one of the two boxes. Not both. – Chris Apr 8 '11 at 9:37
I also cannot post the exact message from my machine, as it is on a separate, closed network. But it is the same message that PriceChild shows above. I also verified that all the zone files in DNS are correct. Even reloaded named and when that still didn't work, rebooted just to make sure any cache was cleared. – Chris Apr 8 '11 at 9:38
Might want to post these as comments or edits to your question rather than 'answers'. I'm afraid this isn't like a 'forum' :-) Do you have something odd set in your ~/.ssh/config ? Did you try deleting the key from the file/line specified like I suggested? – PriceChild Apr 8 '11 at 9:52
FYI I've merged your fragmented accounts together and tidied up the location of what has been posted a bit. If you log in with your Open ID from now on then you'll have the correct ownership of everything you've posted on this thread so far. – DMA57361 Apr 8 '11 at 13:11

It sounds like you are getting the standard message for an unknown host. As you have removed the keys from the known hosts file this is expected. If you accept the key, then you should not be prompted on future connections to the same host.

If ssh is encrypting the address, SSH keeps two keys, one by IP and the other by name. Try removing the IP addresses. As PriceChild has noted you should get a message specifying the offending line in the known_hosts files. You could try removing the IP addresses from the known hosts files using ssh-keygen -R yy and ssh-keygen -R xx.

share|improve this answer
Uuu that -R looks very handy! Have an upvote! :-) – PriceChild Apr 6 '11 at 14:21

Here's an example of my own ssh connection failing host key verification:

[user@host path]$ ssh hostname
The RSA host key for pricey-host has changed,
and the key for the according IP address
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /home/nagios/.ssh/known_hosts:4
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/nagios/.ssh/known_hosts to get rid of this message.
Offending key in /home/nagios/.ssh/known_hosts:15
RSA host key for pricey-host has changed and you have requested strict checking.
Host key verification failed.

The important line is 'Offending key in /home/nagios/.ssh/known_hosts:15' That tells you the exact file and the line number. Do you not see this message?

If it isn't the same as the above, perhaps you could post your exact error and I'll refine my answer, perhaps suggesting ssh -v.

share|improve this answer

Here is the solution for your Problem :

Use the -R option to removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts. If your

remote hostname is, enter:
$ ssh-keygen -R {}
$ ssh-keygen -R {ssh.server.ip.address}
$ ssh-keygen -R**strong text**

Sample output:

/home/vivek/.ssh/known_hosts updated.
Original contents retained as /home/vivek/.ssh/known_hosts.old

You can check out this link too for more information: SSH Host Key Change Error

share|improve this answer

I had this same problem, after I changed the ip address of one of the servers monitored by Nagios3, and since the nagios user does not have a .ssh folder, there are no known_hosts to remove... this on debian.

so, the solution turned out to be quite simple, simply go to the server you try to monitor, and restart the nrpe server, on debian I do it like this:

/etc/init.d/nagios-nrpe-server restart

and, that solved the problem right away.

share|improve this answer

You must log in to answer this question.

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