Cancel SSH connections StrictHostKeyChecking

The default configuration problem

When SSH connection to the remote host, checks the host's public key. If this is the first time the host, the host will display a summary of the public, whether users are prompted to trust the host:

The authenticity of host '192.168.0.110 (192.168.0.110)' can't be established.
RSA key fingerprint is a3:ca:ad:95:a1:45:d2:57:3a:e9:e7:75:a8:4c:1f:9f.
Are you sure you want to continue connecting (yes/no)?

When choose to accept, it will be appended to the file ~ / .ssh / known_hosts in the host's public key. When connected to the host again, it will not prompt the problem. If for some reason (server system reload, the exchange between the server IP address, DHCP, virtual machine rebuild, middleman hijacking), the public key of the IP address has changed, when using SSH connection, will complain:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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
e9:0c:36:89:7f:3c:07:71:09:5a:9f:28:8c:44:e9:05.
Please contact your system administrator.
Add correct host key in /home/jiangxin/.ssh/known_hosts to get rid of this message.
Offending key in /home/jiangxin/.ssh/known_hosts:81
RSA host key for 192.168.0.110 has changed and you have requested strict checking.
Host key verification failed.

The above warning message that is: a public key server has changed, the new public summary is: e9: 0c: 36: 89: 7f: 3c: 07: 71: 09: 5a: 9f: 28: 8c: 44: e9: 05. The original server public key recorded in the file ~ / .ssh / known_hosts row 81. If the confirmation is not a middleman hijacking, you need to connect to the server, how to do it? The easiest is to open with vi ~ / .ssh / known_hosts file, locate the line 81, delete the line, then you can use the ssh connection.

Without connection to the host public key confirmation

When you first connect to the server, the public key will pop up a confirmation prompt. This can result in some automation tasks, as a result of the initial connection to the server automation tasks interrupted. Or due to the ~ / .ssh / known_hosts file contents emptied, resulting in automated task interruption. StrictHostKeyChecking SSH client configuration instructions, can be realized for the first time when the server is connected, automatically accept the new public key. Only need to modify / etc / ssh / ssh_config file that contains the following statement:

Host *
  StrictHostKeyChecking no

Ssh or command line parameters using -o

> ssh  -o StrictHostKeyChecking=no  192.168.0.110

Prevent remote host SSH public key changes result in connection failure

When the confirmation middleman hijacking *** risk is relatively small, you can use the following methods to disable SSH public key to check the remote host. SSH client provides a UserKnownHostsFile configuration, allowing different designated known_hosts file.

> ssh -o UserKnownHostsFile=/dev/null 192.168.0.110
The authenticity of host '192.168.0.110 (192.168.0.110)' can't be established.
RSA key fingerprint is e9:0c:36:89:7f:3c:07:71:09:5a:9f:28:8c:44:e9:05.
Are you sure you want to continue connecting (yes/no)?

Change interrupt message warning prompt first became connected by the public. And StrictHostKeyChecking configuration used in conjunction with the previously mentioned, there is no longer any warning appeared:

> ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null 192.168.0.110
Warning: Permanently added '192.168.0.110' (RSA) to the list of known hosts.
[email protected]'s password:

If no password is set SSH login (ie, public key authentication via client-side), you can connect directly to the remote host. It is a means to automate tasks based on SSH protocol commonly used.