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

Solution 1:

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:


Alternatively you can remove the relevant key by doing the following

ssh-keygen -R (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.

Solution 2:

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.

Solution 3:

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

ssh <server> -o StrictHostKeyChecking=no

Solution 4:

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 ?

Solution 5:

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.