Default configuration issues

When SSH connects to a remote host, the host's public key is checked. If the host is the first time, a summary of the host's public key will be displayed, prompting the user whether 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 you choose to accept, the host's public key is appended to the file ~/.ssh/known_hosts. When the host is reconnected, the problem is no longer prompted. If for some reason (server system reinstallation, IP address exchange between servers, DHCP, virtual machine reconstruction, man-in-the-middle hijacking), the public key of the IP address changes, and when SSH connections are used, an error will be reported:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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 warning message above says that the server public key has changed, and the new public key summary is e9:0c:36:89:7f:3c:07:71:09:5a:9f:28:8c:44:e9:05. The original public key of the server is recorded in line 81 of the file ~/.ssh/known_hosts. What if you confirm that it is not a middleman hijacking and you need to connect to the server? The simplest way is to open the ~/.ssh/known_hosts file with vi, locate it on line 81, delete the line, and then connect with ssh.

No public key confirmation when connecting to the host

When the server is first connected, a public key confirmation prompt pops up. This can lead to some automation tasks, which are interrupted by the initial connection to the server. Or the automation task is interrupted because the ~/.ssh/known_hosts file is empty. SSH client's trictHost Key Checking configuration instructions enable automatic acceptance of new public keys when connecting to the server for the first time. Simply modify the / etc/ssh/ssh_config file to include the following statements:

Host *
  StrictHostKeyChecking no

Or use the - o parameter on the ssh command line

> ssh  -o StrictHostKeyChecking=no  192.168.0.110

Prevent SSH connection failure caused by remote host public key change

When it is confirmed that the risk of hijacking *** by an intermediary is relatively small, the following method can be used to disable public key checking of SSH remote hosts. The SSH client provides a UserKnownHostsFile configuration that allows you to specify different known_hosts files.

> 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)?

The prompt information changes from a public key change interrupt warning to a prompt for the first connection. When used in conjunction with the trictHost Key Checking configuration mentioned earlier, there is no further warning:

> 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.
xxx@192.168.0.110's password:

If SSH login without password is set (i.e. through client public key authentication), it can be directly connected to the remote host. This is a common means of automation tasks based on SSH protocol.