Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Trying to ssh into a computer I control, I'm getting the familiar message:

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a 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/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.

I did indeed change the key. And I read a few dozen postings saying that the way to resolve this problem is by deleting the old key from the known_hosts file.

But what I would like is to have ssh accept both the old key and the new key. The language in the error message ("Add correct host key") suggests that there should be some way to add the correct host key without removing the old one.

I have not been able to figure out how to add the new host key without removing the old one.

Is this possible, or is the error message just extremely misleading?

share|improve this question
This is the host key that is generating the error. A host should have one and only one key. This has nothing to do with client or user keys. Do you have one IP address that floats between distinct hosts or something? –  David Schwartz Oct 13 '11 at 14:05
In my case I know I'm going to be switching between the two keys a lot in the near future while fiddling with some things. It seems this would also be useful in the one IP with multiple hosts situation you suggest. Mainly I just want to know if this is possible for my own education apart from any particular practical application. –  Samuel Edwin Ward Oct 13 '11 at 14:30

8 Answers 8

up vote 41 down vote accepted
  1. get the rsa key of your server:

    $ ssh-keyscan -t rsa server_ip
    # server_ip SSH-2.0-OpenSSH_4.3
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
  2. and on the client, add this key to ~/.ssh/known_hosts:

    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offensive key)
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
share|improve this answer
This worked! However, I'm using "HashKnownHosts", so the entry looked a little out of place. Luckily ssh_config(5) pointed me to ssh-keygen(1) which explained that I can use "ssh-keygen -H" to hash the unhashed entries. Thank you! –  Samuel Edwin Ward Oct 13 '11 at 15:49
This "works" but you are not verifying the key, so you are vulnerable to mitm attacks... –  JasperWallace Sep 23 '13 at 7:22
@JasperWallace, as long as first step is done over secure connection (for example using localhost) it should be pretty secure, I think –  ony Oct 3 '13 at 20:38

Remove that the entry from known_hosts using:

ssh-keygen -R *ip_address_or_hostname*

This will remove the problematic IP or hostname from know_hosts file and try to connect again.

From the man pages

-R hostname
Removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts (see the -H option above). 
share|improve this answer
"how to add the new host key without removing the old one." –  Samuel Edwin Ward Feb 9 '13 at 16:29
This is the best solution ! –  Thomas Decaux Aug 27 '13 at 9:41

The simplest of all is:

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

Then edit known_hosts to clear the original key, then ssh to the host using:

ssh name@computer

It'll add the new key automatically; then compare the two files. A program such as meld is a nice way to make them both contain both keys.

My 'reason' for keeping two keys is that the destination system is multiboot, even though I dare say there's a way of synchronizing the keys across the installations, it seems more straightforward to allow multiple keys.

share|improve this answer
This 'meld'? meldmerge.org –  Samuel Edwin Ward May 1 '12 at 13:16
that's the meld :) apt-get / yum install name is simply meld –  Mark May 7 '12 at 6:27

I don't see why you want to work with two keys, but you can certainly add more than one valid key to the ~/.ssh/known_hosts file, but you will have to do it manually.

Another solution might be to use the StrictHostKeyChecking=no option for this specific host:

ssh -o StrictHostKeyChecking=no user@host

which you could put into an alias in your ~/.profile or something similar.

alias hc=ssh -o StrictHostKeyChecking=no user@host
share|improve this answer
StrictHostKeyChecking does not seem to help in this case; apparently it only specifies the behavior when the host is not in the known_hosts file. Mentioned here: gossamer-threads.com/lists/openssh/dev/45349#45349 –  Samuel Edwin Ward Oct 13 '11 at 15:41
It works here. You will get the warning, but the login continues. –  Sven Oct 13 '11 at 15:53
That's odd. Are you using password authentication? Are you using OpenSSH? –  Samuel Edwin Ward Oct 13 '11 at 16:07

I have the same issue with a raspberry pi which I boot with several different systems (dev system for compiling arm binaries, project, xbmc, etc.) and have run into the same problem. They use DHCP on a local network and my router always reused the same IP since the MAC address was the same. I've solved it by using different domain names in my hosts file: pi-dev pi-xbmc pi-etc

The known_hosts file saves fingerprints by host name so even though it is the same IP address, each unique host name gets a different entry.

I got sick of adding the names to hosts files every time I used a new system so I came up with an even lazier way by using leading zeros on ip addresses like:

$ ssh pi@
$ ssh pi@
$ ssh pi@

Each variation of the (uncanonicalized) ip address gets it's own entry in known_hosts.

share|improve this answer

If you only ssh onto a local network then...

A simple solution is to wipe the old key file and replace it with a blank one. This will allow you to reauthorise all of your connections with new keys. If you have ssh keys stored for sites outside your local network, then you need to ensure that your initial connection is safe as you did the first time you connected to that server.


cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

Then press space, backspace cntl+x and 'y' to save the new buffer (file). Its bad practise but okay providing you aren't regularly ssh'ing outside your local network (eg a uni or work server)

On a secure local network this is safe because you simply cant get a man in the middle attack.

Its always better to use code you understand!

share|improve this answer
Wiping the entire known_hosts file each time is going to negate most of the security otherwise provided by ssh. –  kasperd Jun 15 '14 at 22:23
Indeed, I would argue that on a secure internal network, it is safer to understand your code and circumvent the security than to mindlessly copy code. On an external network then the situation would be different. –  user3157094 Jun 30 '14 at 20:50

I had the same problem.

All I did was sudo nano /home/user/.ssh/ host_allow and erased the key.

When I ssh back to the server it added a new key.

share|improve this answer
Some more information around why this happens would be helpful to the answer. –  Drew Khoury May 18 '14 at 14:56

Use sed command to do remove the offending line

OUTPUT: as show in above example
Offending key in /home/user/.ssh/known_hosts:86

Remove the line 86 as mentioned in known hosts.

sed -i '86d' /home/user/.ssh/known_hosts

Next time when accessing using ssh, system will automatically add new key.

share|improve this answer
"But what I would like is to have ssh accept both the old key and the new key." Your answer does not do this. –  Samuel Edwin Ward Jun 14 '12 at 15: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.