201

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?

chicks
  • 3,639
  • 10
  • 26
  • 36
Samuel Edwin Ward
  • 2,193
  • 2
  • 13
  • 12
  • 11
    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
  • 5
    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
  • @DavidSchwartz +1 about your comment - it would be happening due dynamic IPs in the same LAN – Manuel Jordan Sep 08 '21 at 16:52
  • Or, which brought me here today, a rescue system of course having a different host key, but, and that's why I do NOT want to delete the "old" key, the old key is not old, it's still valid. – Jürgen A. Erhard Apr 05 '22 at 15:13

11 Answers11

190

  1. get the rsa key of your server, where server_ip is your server's IP address, such as 192.168.2.1:

    $ ssh-keyscan -t rsa server_ip

    Sample response:

    # server_ip SSH-2.0-OpenSSH_4.3
server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...

  2. and on the client, copy the entire response line server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG..., and add this key to the bottom of your ~/.ssh/known_hosts file:

    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key, and/or the very bottom of the `known_hosts` file)
server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG... (line you're adding, copied and pasted from above)
Gabriel Staples
  • 161
  • 6
quanta
  • 50,327
  • 19
  • 152
  • 213
  • 14
    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
  • 3
    This "works" but you are not verifying the key, so you are vulnerable to mitm attacks... – JasperWallace Sep 23 '13 at 07:22
  • 3
    @JasperWallace, as long as first step is done over secure connection (for example using localhost) it should be pretty secure, I think – ony Oct 03 '13 at 20:38
  • It could be useful to note that this answer is only valid for OpenSSH, as long as there are some other SSH clients, like Putty or Tunnelier. – Sopalajo de Arrierez Mar 04 '16 at 15:38
  • 3
    Is there any way to gather all key types from server? Sometimes you don't know if they are RSA, DSA, ECDSA, RSA1... etc. – Sopalajo de Arrierez Mar 04 '16 at 15:40
  • @SopalajodeArrierez omit the `-t` option: `ssh-keyscan server_ip` (you can also use hostnames, but that adds another security risk) – kbolino Apr 01 '16 at 03:27
  • @kbolino , from `ssh-keyscan` man page: `The default is to fetch ``rsa'', ``ecdsa'', and ``ed25519'' keys`. – Sopalajo de Arrierez Apr 11 '16 at 03:09
  • 3
    @SopalajodeArrierez the same manpage also says you can separate types with commas, so do `ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip` -- but the only reason to find `rsa1` and `dsa` keys is to identify servers that need to be upgraded/reconfigured – kbolino Apr 12 '16 at 20:31
  • Even better than this answer: `ssh-keyscan -H 192.168.1.162 >> ~/.ssh/known_hosts`. Source: https://www.techrepublic.com/article/how-to-easily-add-an-ssh-fingerprint-to-your-knownhosts-file-in-linux/, and in my comment under this answer: https://serverfault.com/a/631149/357116. I'd add this as my own answer if I could but don't seem to be able to. I lack the necessary reputation, as I have only 3 points gained on this site, not the necessary 10. :( – Gabriel Staples May 14 '19 at 20:25
133

Remove that the entry from known_hosts using:

ssh-keygen -R *ip_address_or_hostname*

This will remove the problematic IP or hostname from known_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).

Evgenia Karunus
  • 127
  • 6
Luis Abarca
  • 1,489
  • 1
  • 9
  • 3
  • 16
    "how to add the new host key without removing the old one." – Samuel Edwin Ward Feb 09 '13 at 16:29
  • 3
    Your question comes up second when I google for "git ssh update host key automatically". This answer is what I was looking for. Opening a new question with exactly what I want might get it closed as a duplicate. – Jason Goemaat Nov 15 '15 at 12:15
  • Hostname works too – damluar Jul 06 '18 at 20:28
  • This works for me. A key was already in there in `known_hosts` file which had changed on remote server. So after removing they key using `ssh-keygen -R *ip_address_or_hostname*`, new key was auto added on next attempt to connect. – Riz Nov 06 '19 at 07:26
  • Perfect - switched a host on aws behind an elastic IP and this did the trick. No need to edit anything. – BooTooMany Jul 22 '20 at 22:23
  • This one works for me on Debian 10 – Seto Aug 26 '21 at 01:37
23

A very simple way 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 compare the two files. Then merge the files to make known_hosts 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.

EDIT 2015/06

I should add, revisiting it now, that I notice an even simpler way [as long as the entry is identifiable, normally from the hostname / IP address quite aside from the error message referencing its specific location];

  1. Edit known_hosts to add # at the start of the 'old' entry in known_hosts temporarily
  2. Connect [ssh to the host], agree to the prompt to add the new key 'automatically'
  3. Then re-edit known_hosts to remove the #

There's even the option HostKeyAlias as in

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

then subsequently, after ssh client adds the new key under the alias, you may either edit known_hosts to substitute the 'real' hostname/IP address for the alias or connect to that incarnation of that host with the alias option evermore

Mark
  • 358
  • 2
  • 5
6

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:

10.10.10.110 pi-dev
10.10.10.110 pi-xbmc
10.10.10.110 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@10.10.10.110
$ ssh pi@010.10.10.110
$ ssh pi@10.010.10.110

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

Mike
  • 181
  • 1
  • 5
  • 1
    The OpenSSH folks got wise to me, this loophole no longer works in more recent versions. – Mike Dec 08 '15 at 03:32
  • You can use `CheckHostIP no` in `~/.ssh/config` to be able to still use the loophole. You can even define your aliases there so you don't have to fiddle with `/etc/hosts` and define `CheckHostIP no` only for this 3 hostnames. – GnP Dec 04 '17 at 18:12
4

If both your client and server have OpenSSH 6.8 or newer, you can use the UpdateHostKeys yes option in your ssh_config or ~/.ssh/config. For example:

Host *
    UpdateHostKeys yes

This makes SSH store all host keys that the server has to known_hosts, and when a server changes or removes one host key, the key is also changed or removed in your known_hosts.

Falcon Momot
  • 24,975
  • 13
  • 61
  • 92
Aminda
  • 141
  • 3
  • This is by far the most useful answer! Although it doesn't explicitly offer a way to resolve the original question if a host key was already changed, all the other answers are insecure since they don't verify the new host key. This option allows you to do secure rollover to new host keys. – Jaap Eldering Jul 05 '17 at 20:03
1

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
Sven
  • 97,248
  • 13
  • 177
  • 225
  • 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: http://www.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
1

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.

eg 

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!

Aaron
  • 132
  • 6
  • 4
    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. – Aaron Jun 30 '14 at 20:50
0

you need to remove old key from client server

ssh-keygen -R 192.168.0.25 #1st remove on client server

then re generate key

ssh -o HostKeyAlias=192.168.0.25 root@192.168.0.25 #on client server

check new line is there

nano ~/.ssh/known_hosts
danone
  • 166
  • 9
-1

So many answers, but so many that give up protection by turning off strict host checking totally, or destroying unrelated host info or just forcing the user to interactively accept keys, possibly at a later point, when it is unexpected.

Here's a simple technique to allow you to leave strict host checking on, but update the key in a controlled way, when you expect it to change:

  • Remove the old key and update in one command

    ssh-keygen -R server.example.com && \
    ssh -o StrictHostKeyChecking=no server.example.com echo SSH host key updated.

  • Repeat with IP address(es) or other host names if you use them.

The advantage of this approach is that it rekeys the server exactly once. Most versions of ssh-keygen seem to not return an error if the server you try to delete doesn't exist in the known hosts file, if this is a problem for you, use the two commands in sequence.

This approach also verifies connectivity and emits a nice message for logs in the ssh command (which logs in, updates the host key, and outputs SSH host key updated then immediately exits.

If your version of ssh-keygen returns a non-zero exit code, and you prefer to handle this without error, regardless or prior connection, simply use the two commands in sequence, ignoring any errors on the ssh-keygen command.

If you use this technique, you never need to vary your ssh command, or turn off host checking except during that one ssh command. You can be sure that future ssh sessions will work without conflict or needing to explicitly accept a new key, as long as the ssh command above ran without error.

markgo2k
  • 99
  • 3
-3

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.

Greg
  • 167
  • 4
david
  • 9
-4

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.

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

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

newer versions of ssh

use: 

ssh-keygen -R <hostname|ip address>

It will remove the hostname entry and take backup of old .known_host as known_hosts.old

chicks
  • 3,639
  • 10
  • 26
  • 36
Viikram Simha
  • 11