Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to disable the remote host to check SSH's public key", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let Xiaobian take you to learn "How to disable remote hosts to check SSH public keys"!

SH public key checking is an important security mechanism, which can prevent hacker attacks such as man-in-the-middle hijacking. However, in certain cases, strict SSH public key checking can break some automated tasks that rely on SSH protocol, so a means is needed to bypass SSH public key checking.

Let's first look at what SSH public key checking is.

When SSH connects to a remote host, it checks the host's public key. If this is the first time the host is used, a digest of the host's public key is displayed, prompting the user whether to trust the host:

The code is as follows:

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

Selecting Accept appends the host's public key to the file ~/.ssh/known_hosts. When the host is connected again, the problem is no longer prompted. If for some reason (server system reload, IP address exchange between servers, DHCP, virtual machine rebuild, man-in-the-middle hijacking), the public key of the IP address changes, when using SSH connection, error will be reported:

The code is as follows:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 said:

The server public key has changed, and the digest of the new public key is: e9:0c:36:89:7f:3c:07:71:09:5a:9f:28:8c:44:e9:05.

The server's original public key is recorded at line 81 in the file ~/.ssh/known_hosts.

What if it is confirmed that it is not a man-in-the-middle hijacking and needs to connect to the server? The easiest thing to do is to open the ~/.ssh/known_hosts file with vi, navigate to line 81, and delete it. Then you can connect using SSH.

How do I connect to a new host without public key validation?

When connecting to the server for the first time, a prompt for public key confirmation pops up. This causes some automated tasks to be interrupted due to initial connection to the server. Or the automation task is interrupted because the ~/.ssh/known_hosts file is empty. The SSH client's strictHostKeyChecking configuration directive automatically accepts a new public key when connecting to the server for the first time. Just modify the/etc/ssh/ssh_config file to include the following statements:

The code is as follows:

Host * StrictHostKeyChecking no

Or use the-o argument on the ssh command line

The code is as follows:

$ ssh -o StrictHostKeyChecking=no 192.168.0.110

How to prevent SSH connection failures caused by remote host public key changes

When you are certain that the risk of man-in-the-middle hijacking is low, disable public key checking for SSH remote hosts using the following method: SSH clients provide a UserKnownHostsFile configuration that allows you to specify different known_hosts files. So pointing known_hosts to a different file won't cause a break due to a public key collision?

The code is as follows:

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

See, the notification went from a public key change interrupt warning to a first time connection alert. With the strictHostKeyChecking configuration mentioned earlier, no more warnings appear:

The code is as follows:

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

If password-less SSH login is set up (that is, through client public key authentication), you can connect directly to the remote host. This is a common tool for automated tasks based on SSH protocol.

At this point, I believe that we have a deeper understanding of "how to disable remote hosts to check SSH public keys," may wish to actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.