62

I have a Linux server that whenever I connect it shows me the message that changed the SSH host key:

$ ssh root@host1 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 93:a2:1b:1c:5f:3e:68:47:bf:79:56:52:f0:ec:03:6b. Please contact your system administrator. Add correct host key in /home/emerson/.ssh/known_hosts to get rid of this message. Offending key in /home/emerson/.ssh/known_hosts:377

RSA host key for host1 has changed and you have requested strict checking. Host key verification failed.

It keeps me for a very few seconds logged in and then it closes the connection.

host1:~/.ssh # Read from remote host host1: Connection reset by peer Connection to host1 closed.

Does anyone know what's happening and what I could do to solve this problem?

Adam Gibbins
  • 7,147
  • 2
  • 28
  • 42
setatakahashi
  • 1,367
  • 2
  • 11
  • 15

6 Answers6

89

Please don't delete the entire known_hosts file as recommended by some people, this totally voids the point of the warning. It's a security feature to warn you that a man in the middle attack may have happened.

I suggest you identify why it thinks something has changed, most likely an SSH upgrade altered the encryption keys due to a possible security hole. You can then purge that specific line from your known_hosts file:

sed -i 377d ~/.ssh/known_hosts

This deletes line 377 as shown after the colon in the warning:

/home/emerson/.ssh/known_hosts:377

Alternatively you can remove the relevant key by doing the following

ssh-keygen -R 127.0.0.1 (obviously replace with the server's IP)

Please DO NOT purge the entire file and ensure this is actually the machine you want to be connecting to prior to purging the specific key.

aknuds1
  • 2,085
  • 3
  • 16
  • 23
Adam Gibbins
  • 7,147
  • 2
  • 28
  • 42
  • Not going to delete over 350 servers because of one key mismatch. Any idea why it keeps closing the connection? – setatakahashi May 09 '09 at 00:25
  • Is it not solved once you remove the relevant known_hosts record? If not, could you run the ssh client in verbose mode and pastebin it somewhere. – Adam Gibbins May 09 '09 at 08:47
  • 1
    It's closing the machine because the host key is invalid, just like it says. If you are serious about security, you need to check with the server's admin to make sure the host key changed for a legitimate reason. If so, you can replace it, as explained by Adam. – Matthew Flaschen May 09 '09 at 19:07
  • I followed your suggestion but $ sed -i "46 d" ~/.ssh/known_hosts sed: 1: "/Users/myusr/.ssh ...": extra characters at the end of l command so I removed it manually with vim and it worked. Thanx! – Luis Ramirez-Monterosa Aug 06 '13 at 16:58
  • 3
    Adam's syntax is nearly correct, but you need a space between the "377" and the "d". Also, in OS X, known hosts is located in ~/.ssh/known_hosts ; note the lack of a "." in the filename. – ktappe Oct 22 '15 at 16:10
34

I think though some of the answers here address the recommended course of action in the OP's question, it does not fully answer the question.

The question states "How to remove strict RSA key checking in SSH and what's the problem here?"

The problem here is, as advised by some others, a change in the host probably due to reinstallation of the server (most common scenario). And the recommended solution is indeed to remove the offending key from the .ssh/authorized_keys file with an inline sed.

However I didnt see any answers address the specific part of the question "How to remove strict RSA key checking in SSH".

You can remove StrictHostKey checking in your ssh configuration file, typically stored at ~/.ssh/config.

An example Host block is provided below:

Host 101
  HostName yourip|hostname
  User youruserid
  IdentityFile /path/to/keyfile
  Port 22
  StrictHostKeyChecking no

The specifically added line is the last one StrictHostKeyChecking no which does just what that. Depending on your specific scenario, this may be useful to you, such as running multiple virtualized containers on a dedicated server, on just a few ips, stopping and starting another instance on the same ip.

Joel G Mathew
  • 890
  • 1
  • 9
  • 18
  • 4
    +1 Because this post actually addresses the strict checking portion of the error message. – Shibumi Mar 24 '15 at 21:46
  • 1
    +1 from me as well for addressing the content of the question. Depending on factors there may be more to do. This approach degrades the host checking from "strict" to "some" (my terminology). In my situation that left ssh with permission to keep me from signing in because the way I wanted to sign in was to enter a password, and that was disabled by "some" host checking. So you have to go ahead and direct ssh to use /dev/null as the "UserKnownHostsFile". This sets host checking to "none" in effect and the above DIRE WARNINGS apply, so don't go doing it globally or permanently. – cardiff space man Sep 29 '15 at 01:12
  • This is really an elegant solution. Thanks for sharing! – LeOn - Han Li Jun 12 '18 at 16:13
16

Another way to remove StrictHostKeyChecking, when you only need to do it for a single server: 

ssh <server> -o StrictHostKeyChecking=no
Greg Dougherty
  • 261
  • 3
  • 6
  • Will let you log in but not fix the issue permanently. – Andres Canella Sep 27 '16 at 15:29
  • When I do it it gives me the chance to add the key, which then fixes the problem permanently – Greg Dougherty Sep 27 '16 at 18:26
  • Perhaps we have different issue? I'm connecting to a server that had a different IP before. – Andres Canella Sep 27 '16 at 23:34
  • If you have a server whose data has changed, then you need to delete it from your known hosts file (after first establishing that the change is correct), and add its new information. If you have a new server, -o will let you connect to the server and get its information added. – Greg Dougherty Sep 29 '16 at 15:48
  • I think it is actually a good practice to keep StrictHostKeyChecking set to YES in your config and only use this switch when you know you're connecting to a new server or have yourself changed the keys on an old server. – mohak Nov 20 '18 at 06:32
6

First of all, is this your machine ? Did you knowingly change the host keys ? If not I would be very concerned that something has altered that data.

Secondly, turn up the ssh debuging,

ssh -vvv user@host

and see what that tells you, also try looking in, /var/log/secure and /var/log/messages on the server you are trying to connect to for clues, sshd gives good error messages.

Thirdly, is this machine connected to the internet ? Should you really be allowing root logins ?

Dave Cheney
  • 18,307
  • 7
  • 48
  • 56
  • 1
    +1 for the root logins comment – Fahad Sadah Jun 20 '10 at 16:17
  • All it takes for this error to occur is the target machine being reimaged. If you are connecting to a target that is on your side of a DMZ, a MitM attack is very unlikely. – ktappe Oct 22 '15 at 16:12
3

You are getting this because something has changed (like new NIC, new IP, change on server software, etc). Security focus has a nice article on SSH host key protection.

Just remove the key (using SFTP or similar) from the server, by editing the $HOME/.ssh/known_hosts file, and accept the new one upon next connection.

Your connection might be getting dropped because of the StrictHostKeyChecking setting. See this thread for a similar issue.

  • 2
    Noooo, please don't do this. This totally voids all security this feature provides. Please only remove the specific key that has changed, not all known_hosts. – Adam Gibbins May 08 '09 at 11:52
  • 5
    I did not recommend to remove the known_hosts file, I recommended to edit it, and remove the key from it. –  May 08 '09 at 11:55
  • Ooop, sorry, misread. – Adam Gibbins May 08 '09 at 11:56
  • 2
    This message can certainly not be triggered by a new IP address, much less by a new NIC. See Adam Gibbins' correct answer. – bortzmeyer May 08 '09 at 12:05
  • 1
    Before you vote down (I am finding people very trigger happy with this), do your research. Read this Security Focus article, http://www.securityfocus.com/infocus/1806. I quote a bit of it: "Why can a host key change? The machine to which you wish to connect has been moved to a different DNS name or IP address, or it's been replaced by a new one entirely." If an answer is horribly incorrect, please allow the chance for a correction. After all, this is a wiki. –  May 08 '09 at 12:14
  • This doesn't explain why I can login but get disconnected afterwards. I connect then I get disconnected and receive this message. I'm connecting to the same IP and still receive the message. – setatakahashi May 08 '09 at 12:26
  • The StrictHostKeyChecking=no configuration entry on your SSH server will refuse a connection when key changed. –  May 08 '09 at 12:37
  • +1 for the article link. Very helpful. – KevDog Mar 18 '13 at 16:06
3

As the 'host' [broadly defined, it could be everything from a reinstallation / multiboot to an entirely different computer with an IP address you've connected to before, for instance] appears to the ssh client to have changed, it's giving you the error.

It is unnecessary to switch off strict checking, nor is wholesale deletion of saved keys sensible.

It is quite possible to have two different keys listed in known_hosts for a particular hostname or IP address; giving you 2 alternatives according to whether you think you may need the 'old' key that is currently stored in known_hosts

Either delete the particular key it is referring to, at l377 of known_hosts for the OP, or keep both

The simplest way to keep both, avoiding deletion of keys in known_hosts, is

  1. Edit known_hosts to add # at the start of the 'old' entry referenced in known_hosts [@l377] 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 #

more answers at "Add correct host key in known_hosts" / multiple ssh host keys per hostname?

Community
  • 1
Mark
  • 358
  • 2
  • 5