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.

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.

    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.

  2. 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

  3. 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.

  4. 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.

  5. I had same problem.,, i tried to used Amos Sapira suggest.
    #ssh-keygen -R ip_that_have_problem

    and.. IT WORKS..
    thanx a lot guys…
    Regard … TGUNTARA

  6. 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.

  7. 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.

  8. 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.

    ;-)

  9. Thank you for the post, this helped me get back into my ipod 2 gen after I messed up badly by accidentally removing the folder labeled System. You’re awesome!

  10. 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.

  11. 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:

  12. 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.

  13. 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

  14. 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?

  15. 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…

  16. 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@

  17. Open File manager, enter to /home/user/ssh/ and open file known_host. edit file and remove content. finish: saving
    Olala… resolved.

  18. What to do when the “bad” key is not in the normal place $HOME/.ssh/known_hosts, but it’s located in /var/lib/sss/pubconf/known_hosts? No solution works.

    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.

Leave a Comment