SSH communication is secured using public key cryptography. When a user connects to the SSH-server using SSH-client for the first time, the SSH program stores the SSH-server public key in the user’s home directory inside a file, known_hosts, in a hidden folder named ~/.ssh/, as shown in the following screenshot:
Now, subsequently, whenever the ssh-client connects to the server, it compares the public key sent by the server to the public key of the server stored in the ~/.ssh/known_hosts file. If the public key does not match, the client assumes that the network traffic is being hijacked or the server to which the connection is being made is not the same, and hence SSH client breaks the connection, as shown here:
$ ssh admin@192.168.12.12 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 3f:1b:f4:bd:c5:aa:c1:1f:bf:4e:2e:cf:53:fa:d8:59. Please contact your system administrator. Add correct host key in /home/admin/.ssh/known_hosts to get rid of this message. Offending key in /home/admin/.ssh/known_hosts:3 RSA host key for 192.168.12.12 has changed and you have requested strict checking. Host key verification failed.$
There are multiple possible reasons why the remote host key changed. A Man-in-the-Middle attack is only one possible reason. Other possible reasons include:
- OpenSSH was re-installed on the remote host but, for whatever reason, the original host key was not restored.
- The remote host was replaced legitimately by another machine.
It is also a possibility that the server was reformatted or the server key replaced for any legitimate reason. In such circumstances, the user needs to update their ~/.ssh/known_hosts files by deleting the old keys to enable logging in to the server.
If you are sure that this is harmless, you can use either 1 of the 2 methods below to trick openSSH to let you login. But be warned that you have become vulnerable to man-in-the-middle attacks.
Method 1 – remove host key from ~/.ssh/known_hosts file
The first method is to remove the remote host from the ~/.ssh/known_hosts file. Note that the warning message already tells you the line number in the known_hosts file that corresponds to the target remote host. The offending line in the above example is line 3(“Offending key in /home/admin/.ssh/known_hosts:3”)
You can use the following one-liner to remove that one line (line 3) from the file.
$ sed -i 3d ~/.ssh/known_hosts
Note that with the above method, you will be prompted to confirm the host key fingerprint when you run ssh to login.
Method 2 – Disable StrictHostKeyChecking
The second method uses two openSSH parameters:
- StrictHostKeyChecking
- UserKnownHostsFile
This method tricks SSH by configuring it to use an empty known_hosts file, and NOT to ask you to confirm the remote host identity key.
$ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no admin@192.168.12.12 Warning: Permanently added '192.168.12.12' (RSA) to the list of known hosts. admin@192.168.12.12's password:
The UserKnownHostsFile parameter specifies the database file to use for storing the user host keys (default is ~/.ssh/known_hosts). The /dev/null file is a special system device file that discards anything and everything written to it, and when used as the input file, returns End Of File immediately.
By configuring the null device file as the host key database, SSH is fooled into thinking that the SSH client has never connected to any SSH server before, and so will never run into a mismatched host key. The parameter StrictHostKeyChecking specifies if SSH will automatically add new host keys to the host key database file. By setting it to no, the host key is automatically added, without user confirmation, for all first-time connections. Because of the null key database file, all connection is viewed for the first time for any SSH server host. Therefore, the host key is automatically added to the host key database with no user confirmation. Writing the key to the /dev/null file discards the key and reports success.
By specifying the above 2 SSH options on the command line, you can bypass host key checking for that particular SSH login. If you want to bypass host key checking on a permanent basis, you need to specify those same options in the SSH configuration file. You can edit the global SSH configuration file (/etc/ssh/ssh_config) if you want to make the changes permanent for all users.
If you want to target a particular user, modify the user-specific SSH configuration file (~/.ssh/config). The instructions below apply to both files. Suppose you want to bypass key checking for a particular subnet (192.168.0.0/24).
Add the following lines to the beginning of the SSH configuration file.
Host 192.168.0.* StrictHostKeyChecking no UserKnownHostsFile=/dev/null
Note that the configuration file should have a line like Host * followed by one or more parameter-value pairs. Host *means that it will match any host. Essentially, the parameters following Host * are the general defaults. Because the first matched value for each SSH parameter is used, you want to add the host-specific or subnet-specific parameters to the beginning of the file.
As a final word of caution, unless you know what you are doing, it is probably best to bypass key checking on a case by case basis, rather than making blanket permanent changes to the SSH configuration files.