Fix the SSH "Remote Host Identification Has Changed" Error
Every SSH server uses a random key to identify itself. When SSH is installed a new key is generated. SSH clients keep track of the host key, if it changes the user can be warned that they might not be connecting to the computer they think they are. Most of the time this happens when the SSH server or the OS are reinstalled.
In the case of the SSH client in Linux, a changed host key results in the client
refusing to connect and showing an remote host identification has changed
error.
The easiest way to fix the problem is to delete the known_hosts file:
rm ~/.ssh/known_hosts
This causes the SSH client to forget all the host keys it knows about. Next time you connect, it will create the file again and ask you before adding the new key.
The version of SSH installed in Ubuntu does not produce a known_hosts file
that is easily readable. Unless you are paranoid about security, simply deleting
it is safe.
Archived Comments
jorge
Sorry, looks like your blog truncated my command:
ssh-keygen -R hostname
is the proper syntax.
Christer Edwards
A more secure way is to only delete the line in conflict. Generally when SSH complains about a key change it tells you the line of the host that is in conflict.
I generally use:
vim .ssh/know_hosts +{line number}, dd (delete line), :x.
Kirrus
Very similar to Christer Edwards, I tend to use vim to delete the line.
vi .ssh/know_hosts [ENTER]
:{line number} [ENTER]
dd [ENTER] (dd = delete line)
:wq [ENTER] (w = write, q = quit)
Stefano Rivera
Another method:
sed -i 5d .ssh/known_hosts
(assuming line-number = 5)
Jonathan Hitchcock
For goodness sake, please do not go advocating that people just remove their known_hosts file every time they get a warning! The file is there for a reason! Please make it clear that they must check why the key has changed, and if they know that the remote system has been reinstalled, then they can change that ONE key, using the method that Stefano has given. Simply crushing all of OpenSSH’s attempts at security to get rid of a helpful warning is very counter-productive, and you should not be advocating it on Planet Ubuntu.
Tomasz
This post is very misleading. Clearly SSH is for security, and the message (it is not en error) tells you that somebody is trying to break your security. This is the only conclusion you may make.
Of course, sometimes this might be just the server’s admin fault, but in that case you need to be 100% sure that this is the case and you need to get the new key fingerprint through a secure channel.
Your advice is just like saying that when you see a red blinking light “Breaks not working” in your car, you should just remove the red bulb and go drive.
anon
this is a really dumb advice. why not proposing to fully reinstall the OS while you’re at it ?
this advice may be usable only if:
1) you made sure there’s no security risk at hand
2) you only have one 1 key stored in the known_hosts
in any other case you should *not* use this way to fix the problem. once made sure this is not caused by a security threat, only remove the key causing trouble, not the whole file.
whatsinaname
Umm Ok, so if I already deleted the known_hosts file, how do I go about making sure my security is still good. the only reason this happened to me is ssh was updated. This broke my nx client connection and I was in a hurry to fix it. any suggestions?
Kaedn
Wait, I cannot fathom it being so stragithofwrard.
Anonymous
Anyone know of a way to disable this check or have it automagically update the known host file without question? It breaks our server failover… i.e. When we failover to a new server, ssh breaks…
Fabio
Thanks a lot man! You’re tutorials are the best ever! This problem was bugging me a bunch today! :D keep up the awesome posts!
Anonymous
In the case of server fail-over it would be preferable to use the same
/etc/ssh/ssh_host_rsa_key.pub
/etc/ssh/ssh_host_dsa_key.pub
on every identical server. Copy those files to each server instead of disabling
ssh security features.
If there is a key error like this I have the server “admin” run
find /etc/ssh/ -name ‘*.pub’ -exec ssh-keygen -lf {} \;
and send me the output via e-mail. So I can verify that I’m really connecting to
them.
proctor
Tom’s advice is fine if you know what you are doing. There is no point in
crapping on him. He probably presumes a higher caliber audience.
I only do ssh on a private LAN. Some of the machines get their address via DHCP.
Machines come in and out of my LAN often enough that I get that infernal error.
I used to be able edit the known_hosts file in other distributions, but now the
entries are encrypted.
“ssh-keygen -R host” is the answer that I wanted though.
simon
I agree, don’t crap on the poster for suggesting a fix to a problem advanced users have. I’ve been wondering how to get around this myself for ages, as I develop on appliances that always come up with the same IP, but unique ssh keys. I too was unaware of ssh-keygen -R host – thanks!
Anwar Khan
thanks a lot guyzzz…it works..rm -rf .ssh/known_hosts
Beaker
If you do not know the line number of the entry to be deleted you can use the following command to delete the host:
sed -i ‘/hostname/d’ ~/.ssh/know_hosts
Amine
Great stuff thank you!
John
ssh-keygen -R hostname
worked great.
jorge
“ssh-keygen -R ” will fix the problem without you having to blow away your known_hosts file.