Warning: Remote Host Identification Has Changed error and solution

Posted on in Categories , , , , , , , last updated November 22, 2016

When I run ssh command I get an error which read as follows:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
5c:9b:16:56:a6:cd:11:10:3a:cd:1b:a2:91:cd:e5:1c.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:1
RSA host key for ras.mydomain.com has changed and you have requested strict checking.
Host key verification failed.

How do I get rid of this message?

If you have reinstalled Linux or UNIX server with OpenSSH, you will get the above error from client computer as follows:

Fig.01: "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED" error
Fig.01: “WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED” error

To get rid of this problem add correct host key in $HOME/.ssh/known_hosts. You can try the following command to get rid of offending key. Only use the following commands if you have changed the ssh key or modified by new operating system installation or the recent OpenSSH server installation.

Solution #1: Remove keys using ssh-keygen

Use the -R option to removes all keys belonging to hostname from a known_hosts file. This option is useful to delete hashed hosts. If your remote hostname is server.example.com, enter:
$ ssh-keygen -R {server.name.com}
$ ssh-keygen -R {ssh.server.ip.address}
ssh-keygen -R {ssh.server.ip.address} -f {/path/to/known_hosts}
$ ssh-keygen -R server.example.com
Sample output:

/home/vivek/.ssh/known_hosts updated.
Original contents retained as /home/vivek/.ssh/known_hosts.old

Now, you can connect to the host without a problem.

Solution #2: Add correct host key in /home/user/.ssh/known_hosts

It is not necessary to delete the entire known_hosts file, just the offending line in that file. For example if you have 3 server as follows.
myserver1.com,64.2.5.111 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA11FV0EnGahT2EK8qElocjuHTsu1jaCfxkyIgBTlxlrOIRchb2pw8IzJLOs2bcuYYfa8nSXGEcWyaFD1ifUjfHelj94AAAAB3NzaC1yc2EAAAABIwAAAIEA11FV0E
nGahT2EK8qElocjuHTsu1jaCfxkyIgBTlxlrOIRchb2pw8IzJLOs2bcuYYfa8nSXGEcWyaFD1ifUjfHelj94H+uv304/ZDz6xZb9ZWsdm+264qReImZzruAKxnwTo4dcHkgKXKHeefnBKyEvvp/2ExMV9WT5DVe1viVwk=
myserver2.com,125.1.12.5 ssh-rsa
AAAAB3NzaC1yc2EAAAABIwAAAQEAtDiERucsZzJGx/1kUNIOYhJbczbZHN2Z1gCnTjvO/0mO2R6KiQUP4hOdLppIUc9GNvlp1kGc3w7B9tREH6kghXFiBjrIn6VzUO4uwrnsMbnAnscD5EktgI7fG4ZcNUP 5+J7sa3o+rtmOuiFxCA690DXUJ8nX8yDHaJfzMUTKTGxQz4M/H2P8L2R//qLj5s3ofzNmgSM9lSEhZL/IyI4NxHhhpltYZKW/Qz4M/H2P8L2R//qLj5s3ofzNmgSM9lSEhZL/M7L0vKeTObue1SgAsXADtK3162a/Z6MGnAazIviHBldxtGrFwvEnk82+GznkO3IBZt5vOK2heBnqQBfw=
myserver3.com,125.2.1.15 ssh-rsa
5+J7sa3o+rtmOuiFxCA690DXUJ8nX8yDHaJfzMUTKTGx0lVkphVsvYD5hJzm0eKHv+oUXRT9v+QMIL+um/IyI4NxHhhpltYZKW
as3533dka//sd33433////44632Z6MGnAazIviHBldxtGrFwvEnk82/Qz4M/H2P8L2R//qLj5s3ofzNmgSM9lSEhZL/M7L0vKeTObue1SgAsXADtK3162a/Z6MGnAazIviHBldxtGrFwvEnk82+GznkO3IBZt5vOK2heBnqQBfw==
To delete 2nd server (myserver.com), open file:
# vi +2 .ssh/known_hosts
And hit dd command to delete line. Save and close the file. Or use following
$ vi ~/.ssh/known_hosts
Now go to line # 2, type the following command
:2
Now delete line with dd and exit:
dd
:wq

Or you can use the sed command as follows to delete offending key at line # 44:
$ sed -i 44d ~/.ssh/known_hosts

Solution 3: Just delete the known_hosts file If you have only one ssh server

$ cd
$ rm .ssh/known_hosts
$ ssh ras.mydomain.com

Try connecting with ssh again

Now you should be able to connect your server via ssh:
ssh [email protected]
ssh [email protected]
Next, you will get a fresh prompt to add key to ~/.ssh/known_hosts as follows:

The authenticity of host '10.86.115.66 ()' can't be established.
ECDSA key fingerprint is 4e:10:42:39:53:85:7f:89:89:dc:89:84:8d:79:e7:ed.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.86.115.66' (ECDSA) to the list of known hosts.

Posted by: Vivek Gite

The author is the creator of nixCraft and a seasoned sysadmin and a trainer for the Linux operating system/Unix shell scripting. He has worked with global clients and in various industries, including IT, education, defense and space research, and the nonprofit sector. Follow him on Twitter, Facebook, Google+.

Share this on:

63 comment

  1. It’s not necessary to delete the entire known_hosts file, just the offending line in that file.

    Using your example, all you need to do is:

    vi ~/.ssh/known_hosts
    1G
    dd
    :wq

    And done. This is helpful if you manage a large group of servers and have *many* keys cached. If you delete the entire file, you will br prompted to add the server’s key on each connection attempt.

    Reply Report comment

    1. I have an easier way to just delete the one offending key:

      EXAMPLE: sed -i ‘2d’ .ssh/known_hosts

      Just replace the 2 in the example above with whatever line it says contains the offending key.

      Reply Report comment

  6. Thanks for nice solution.

    The above mentioned problem I face when remote computer completely formated and they give us again ssh connection. And because of RSA digital signature of computer identification the local computer does not accept the remote computer (as I think).

    Once again thanks for solution.

    Regards,
    Deepen

    Reply Report comment

  7. Thanks, your solution worked for my SSH login. Currently still can’t log in properly through my ltsp server. It says it is checking the password and then ends the session. I definitely have a link to the server (i.e. and address) Any ideas about this? Thank-you in advance.

    Reply Report comment

  10. Hi,
    I’m getting the same error. I compared the RSA keys in my known_hosts file with the host key of the remote computer….they are the same. I thought I’d find out if it is a genuine MITM attack or not, so I shut down the SSH server on the remote machine and accepted the newly presented key. Connection to the remote machine now yields a “Permission denied” message, since I use public-private key authentication.

    Does this mean that I am, in fact, being subjected to a MITM attack?

    Thanks.

    Reply Report comment

  16. in my case I had another problem:
    I had set the options
    UserKnownHostsFile=no
    StrictHostKeyChecking=no
    in my config and this prevented the new host to be added to known_hosts. I got the error every time I tried to contact the host and never got a prompt to add it to known hosts.

    Reply Report comment

  17. Big help especially solution number 3. :)
    Finally get rid of that error message. Made me really paranoid of the “eavesdropping” thing.

    Thanks a lot for the tip.

    Reply Report comment

  19. got one better for you.

    ssh -1 host fails, asking for password, even though pub key is correct on remote host.
    subsequent ssh -1 host fails with man-in-the-middle warning. this is an endless cycle.

    ssh -2 host works fine from the command line. from the veritas netbackup NBU_include.pl script, that same command fails on auth error.

    ;-)

    Reply Report comment

  27. Hi guys,

    thanks fo rthe solution I have also one query when I am doing vncviewer 10.1.1.1:3 (example) then I am getting the message “vncviewer : unable to open dislpay ‘0.0’ “.
    what may be the problem . I checked with echo $DISPLAY >>> it is 0.0.

    Reply Report comment

  38. So – I can’t really tell you if any of these solutions work. There’s another Problem in my warning message:

    It says:
    “Add correct host key in /Users/jannis/.ssh/known_hosts to get rid of this message.”

    Buuut – there is no directory called “/Users/jannis/….” – so I can’t really find this file.
    By the way: the file isn’t in my home directory either.

    Please tell me anybody has a solution for this D:

    Reply Report comment

  41. Hey There.

    I encountered this same issue with a reinstalled ubuntu server. None of the three solutions above worked for me but I found a solution that did. The problem was that there was no known_hosts file at all. So, using an ftp client I created the .ssh folder in my user director and then added a file called known_hosts. BEFORE editing the file I tried to ssh in to my server and presto, it worked. Hopefully this helps someone else out.

    Reply Report comment

  42. I was booting the same hardware with different media, so completely different OSs and needed BOTH ssh keys to work. The solution
    ssh-keyscan -t rsa ip_address >> ~/.ssh/known_hosts

    Reply Report comment

  44. So I have been hunting for an answer to “how do you determine if the key has actually changed, or you are subject to MITM?”

    I haven’t changed the remote server’s keys, and I have confirmed that the fingerprint matches, so I am now stuck – what should I do?

    Reply Report comment

  47. Thanks …..nice solution…i would like to thanks nixCraft team ….. i m always found the correct explanations and solutions from here ………thanks a lot…..keep it up…

    Reply Report comment

  49. Since I do a lot of internal testing and re-imaging of servers where I SSH to these servers quite a bit I’d rather not delete the offending key in known hosts, delete the all the files I run this:

    ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@

    Reply Report comment

    1. The syntax is:
      ssh-keygen -f /var/lib/sss/pubconf/known_hosts -R ip_address_here
      ssh-keygen -f /var/lib/sss/pubconf/known_hosts -R host-example-com
      Or Edit file with a text editor such as vi:
      vi /var/lib/sss/pubconf/known_hosts
      And delete the line.

      Reply Report comment

Leave a Comment

Tagged as: Tags , , , , , , , , , , ,