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


“ssh-keygen -R ” will fix the problem without you having to blow away your known_hosts file.


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.


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.


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.


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.


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?


Wait, I cannot fathom it being so stragithofwrard.


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…


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!


In the case of server fail-over it would be preferable to use the same
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.


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.


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


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


Great stuff thank you!


ssh-keygen -R hostname

worked great.

Respond via email