The SSH protocol can be used for remote management channel security protection, and the main security functions involved include host authentication, data encryption, and data integrity protection.
What should be noted here is the difference between [Host Verification] and [Identity Verification]. Host verification is when the client confirms that the server being accessed is the target access object, such as connecting from client A (192.168.3.1) to server B ( 192.168.3.133), you need to verify that server B is authentic. When the host verification is passed, the identity verification phase will be entered. SSH supports multiple authentication mechanisms, and their verification order is as follows: gssapi-with-mic, hostbased, publickey, keyboard-interactive, password, but the most common ones are password authentication mechanism (password) and public key authentication mechanism (public key).
If the SSH client logs in for the first time or deletes the corresponding server-side host key value in [Computer\HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys] in the Windows registry, for example. (For example, Putty) Use ssh to log in to the server, and the following prompt will pop up:
The host key is not cached for this server:
192.168.3.133 (port 22)
You have no guarantee that the server is the computer you think it is.
The server's ssh-ed25519 key fingerprint is:
ssh-ed25519 255 SHA256:gFoFqs17V915WdaNspPRsCPu8g9McWt5Hduo6RLhK5I
If you trust this host, press "Accept" to add the key to PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without adding the key to the cache, press "Connect Once".
If you do not trust this host, press "Cancel" to abandon the connection.
Open more info to see
Full text of host’s public key
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAxMDpul0HDFVD4NAYw8rk0Ex1bDGsqWCDALE0FBzajw
SHA256 fingerprint gFoFqs17V915WdaNspPRsCPu8g9McWt5Hduo6RLhK5I
MD5 fingerprint 13:9d:92:62:1a:ca:7e:77:f7:ab:89:2e:f3:a0:1f:20
Click accept, and a new entry will be added in the Windows registry with the data value
0x6e326c40573f5fffb8224daceab4ac24050a609ff50ce518e4a27cadc52a848d,0x70a8cd4141130b300896ca1ac356c7044dae3c8c010d3e54c570d0a59b0e4c0c
Subsequently, the client will no longer see the previous prompt. Instead, it will obtain the public key sent from server B and compare it with the local public key fingerprint. If they are consistent, the verification is successful.
At this point, we can look at the corresponding relationship between the public key and the public key fingerprint, as follows:
Base64 encoded server public key (can be found in the client's prompt window, or in the server's /etc/ssh directory)
AAAAC3NzaC1lZDI1NTE5AAAAIAxMDpul0HDFVD4NAYw8rk0Ex1bDGsqWCDALE0FBzajw
Corresponds to HEX encoded server public key (base64 to hex)
0000000B7373682D65643235353139000000200C4C0E9BA5D070C5543E0D018C3CAE4D04C756C31ACA9608300B134141CDA8F0
Calculate the SHA256 hash of the server public key to get it
805A05AACD7B57DD7959D68DB293D1B023EEF20F4C716B791DDBA8E912E12B92
Convert to base64 to get gFoFqs17V915WdaNspPRsCPu8g9McWt5Hduo6RLhK5I=, which is consistent with the SHA256 public key fingerprint prompted by the putty window.
The MD5 hash calculation of the server public key yields 139D92621ACA7E77F7AB892EF3A01F20, which is consistent with the MD5 public key fingerprint prompted by the putty window.
Finally, through packet capture, we can see in which message the public key of server B is sent to the client. The specific packet capture information is as follows.
Search for the 0C4C hexadecimal value in wireshark and find it in the Key Exchange Reply message sent by the server. You can see that the content in the EdDSA public key field is completely consistent with the yellow portion of the HEX-encoded public key information, so the server's public key is sent to the client in this message.
So what is this part [0000000B7373682D6564323535313900000020]? Converting HEX to ASCII code is ssh-ed25519, which is the algorithm for generating public and private key pairs.
