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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
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?

link|improve this question
4  
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
feedback

3 Answers

up vote 3 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...
    
link|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
feedback

simplest of all, is

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

then edit known_hosts to clear the original key, then

ssh name@computer

it'll add the new key automatically; then compare the 2 files — a program such as meld is a nice way — to make them both contain both keys

my 'reason' for keeping 2 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

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

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
link|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. – SvenW 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
feedback

Your Answer

 
or
required, but never shown

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