2022-10-29 PuTTY officially released 0.78 released . The most significant change in this update is support for OpenSSH certificates for user authentication keys and host keys . For this reason, cnPuTTY has also been updated simultaneously. Please check the release information for related content .
In the process of updating cnPuTTY, we simply generated the CA key and issued the certificate for the test public key, which was used to load it into cnPuTTYgen for testing the adding and deleting functions of keys and certificates and testing the certificate-related functions of cnPageant . There is no further exploration into the use of related functions in PuTTY/cnPuTTY. Recently, I discovered some very strange problems when checking the information related to using certificates for login in SSH: After searching for related content, I found that most of the documents on "Using Certificates for Login in SSH" describe the use of "public key authentication". ", simply regard the public key or private key as certificate authentication to describe related issues. What's more, adding the public key generated by PuTTYgen to the server is defined as "public key login"; taking down the id_rsa key generated by the user on the server and using it to log in is defined as "private key login". Maybe there is something wrong with the search method, and I only see these related information? These definitions are incorrect. A key or public key is not equivalent to a certificate, at least not in the relevant protocol description. Or maybe everyone’s understanding is different, so it’s up to the readers themselves! !
In fact, the above operation is essentially authentication through the public key system, but the source or generation method of the public key or private key used is different, and it cannot be called "certificate login under SSH". Generally, there will be an issuing authority and certificate issuance actions in the certificate system. The issuance and certificate files do not appear in the above related descriptions. In addition, in the SSH certificate related protocols, the data format and extension of the relevant certificates are clearly defined. Please refer to: Public key certificate authentication system used in SSH [Reprint]~~ . None of the above operations involve relevant protocols and data, so they cannot be considered correct, at least they cannot be considered "certificate login under SSH". Among other related instructions found, " Ruan Yifeng's network log - SSH certificate login tutorial " and " Zhufengzhuye - SSH certificate login " are true and provide a relatively detailed description of the use of certificates in SSH. , very reference.
The main purpose of this document is to provide instructions for logging in to PuTTY/cnPuTTY with certificate authentication. It also describes logging in to PuTTY/cnPuTTY in other ways, and provides event log output for comparison. The other is to collect some cnPuTTY error information to modify cnPuTTY. The recording process may involve key generation programs in three different locations, namely the Debian key generation in the virtual machine, the Git Bash key generation in the real host, and the key generation program in cnPuTTY. The source of the key/public key may also come from different locations. The specific source used is subject to the description information.
The relevant basic settings of the SSH server are not discussed. The premise here is that there is already an available SSH server and normal login access using a password or key is allowed. The logged-in client selects cnPuTTY. Of course, PuTTY is the same. It just collects some error information for modification.
1. Use password to log in
As you can tell, there seems to be little to describe this. Enter the IP address directly, the port number is default, then save and select to open. A first-time connection warning message will pop up, then select Accept.
Enter your account and password to log in. After logging in,
Event logging:
//使用账户密码进行登陆的事件日志
2022-11-22 12:33:27 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-22 12:33:27 连接到 192.168.204.128 端口 22
2022-11-22 12:33:27 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-22 12:33:27 连接到 192.168.204.128
2022-11-22 12:33:27 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-22 12:33:27 使用SSH协议版本 2
2022-11-22 12:33:27 没有GSSAPI安全可用的上下文
2022-11-22 12:33:27 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-22 12:33:27 服务器也有ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-22 12:33:27 主机密钥指纹是：
2022-11-22 12:33:27 ssh-ed25519 255 SHA256:nLn7QFEy1Ru+S9ZgFPZbtAJoUT2k3Pfk816OsBxTzRg
2022-11-22 12:33:27 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-22 12:33:27 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-22 12:33:27 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-22 12:33:27 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-22 12:33:35 发送密码
2022-11-22 12:33:35 授予访问权限
2022-11-22 12:33:35 打开主会话通道
2022-11-22 12:33:35 已开通主通道
2022-11-22 12:33:35 已分配 pty
2022-11-22 12:33:35 已启动 shell/command
Please note that in the event log, relevant authentication information: host ssh-ed25519 key fingerprint; locally sent password provides authentication.
2. Use public key authentication system
For specific related processes, you can refer to other documents, or you can refer to the relevant content in Chapter 8.3 Preparing for Public Key Authentication in the cnPuTTY built-in manual . Here, use the cnPuTTYgen program to generate relevant keys, and use your most convenient method to save the public key information to the /.ssh/authorized_keys file in the login user directory. It is also possible to use information about the user key that exists on the server.
Enter username in data panel
Specify the user key file in the credentials panel
Then save and select Open to log in automatically. Because I have logged in before and saved the host key, there is no warning. After logging in
Event logging:
//使用公钥系统进行登陆的事件日志——直接指定密钥文件
2022-11-22 12:53:17 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-22 12:53:17 连接到 192.168.204.128 端口 22
2022-11-22 12:53:17 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-22 12:53:17 连接到 192.168.204.128
2022-11-22 12:53:17 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-22 12:53:17 使用SSH协议版本 2
2022-11-22 12:53:17 没有GSSAPI安全可用的上下文
2022-11-22 12:53:17 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-22 12:53:17 服务器也有ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-22 12:53:17 主机密钥指纹是：
2022-11-22 12:53:17 ssh-ed25519 255 SHA256:nLn7QFEy1Ru+S9ZgFPZbtAJoUT2k3Pfk816OsBxTzRg
2022-11-22 12:53:17 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-22 12:53:17 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-22 12:53:17 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-22 12:53:17 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-22 12:53:17 读取密钥文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack.ppk"
2022-11-22 12:53:17 提供的公钥
2022-11-22 12:53:17 接受提供的公钥
2022-11-22 12:53:17 发送公钥签名
2022-11-22 12:53:17 授予访问权限
2022-11-22 12:53:17 打开主会话通道
2022-11-22 12:53:17 已开通主通道
2022-11-22 12:53:17 已分配 pty
2022-11-22 12:53:17 已启动 shell/command
Please note that in the event log, the relevant authentication information: the host ssh-ed25519 key fingerprint still exists; the local authentication is changed from the previous sending password to reading the key file, and sending the relevant information of the public key to the server for relevant authentication.
Of course, you can also use the cnPageant identity agent program to manage keys for login. Other settings remain unchanged, except that the key is loaded into the agent program for use. The event log is as follows:
//使用公钥系统进行登陆的事件日志——使用cnPageant
2022-11-22 13:23:50 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-22 13:23:50 连接到 192.168.204.128 端口 22
2022-11-22 13:23:50 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-22 13:23:50 连接到 192.168.204.128
2022-11-22 13:23:50 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-22 13:23:50 使用SSH协议版本 2
2022-11-22 13:23:50 没有GSSAPI安全可用的上下文
2022-11-22 13:23:50 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-22 13:23:51 服务器也有ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-22 13:23:51 主机密钥指纹是：
2022-11-22 13:23:51 ssh-ed25519 255 SHA256:nLn7QFEy1Ru+S9ZgFPZbtAJoUT2k3Pfk816OsBxTzRg
2022-11-22 13:23:51 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-22 13:23:51 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-22 13:23:51 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-22 13:23:51 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-22 13:23:51 Pageant正在运行中,尝试请求密钥
2022-11-22 13:23:51 Pageant有 9 个SSH-2密钥
2022-11-22 13:23:51 尝试Pageant中的密钥 #0
2022-11-22 13:23:51 服务器拒绝了我们的密钥
2022-11-22 13:23:51 尝试Pageant中的密钥 #1
2022-11-22 13:23:51 服务器拒绝了我们的密钥
2022-11-22 13:23:51 尝试Pageant中的密钥 #2
2022-11-22 13:23:51 发送Pageant的回应
2022-11-22 13:23:51 授予访问权限
2022-11-22 13:23:51 打开主会话通道
2022-11-22 13:23:51 已开通主通道
2022-11-22 13:23:51 已分配 pty
2022-11-22 13:23:51 已启动 shell/command
Please note that in the event log, the relevant authentication information: the host ssh-ed25519 key fingerprint still exists; local authentication uses the cnPageant identity agent to provide key information. When multiple keys exist in the agent, they will be automatically matched.
At this point, the conventional SSH login authentication operation has been introduced. From the above process, it can be seen that there is indeed no relevant information about the certificate. Before introducing certificate authentication in SSH, we must first discuss some additional questions: Why use certificates? ? If the above requirements have been met, is it necessary to use a certificate? ?
For regular use, the above can meet the basic requirements, but as the number of hosts or users increases, the number of authorized key files increases, making it difficult to manage. If you use a certificate, as long as the user CA trusted by the server is used to issue a certificate to the newly added user, the user can log in using the certificate and key, and the server does not need to make any changes. The generation and use of the key have no user attributes and time attributes. As long as the key exists, anyone can use it after obtaining it, and as long as the public key information is not deleted from the server, the key will be permanently valid, but whether the key Safety and reliability cannot be guaranteed. If you use a certificate, you can bind the user identity, and the certificate can specify a validity period. You can specify a certificate that is valid for a short period of time, such as 1 hour or a month. It will automatically expire after expiration and the server does not need to make any changes. In addition, as described in the SSH Certificate Authentication Protocol , certificates can contain a variety of data and can impose restrictions on SSH login, such as prohibiting PTY allocation or port forwarding, disabling X11 forwarding, etc. Please learn about other advantages of using certificates by yourself. Whether you need to use a certificate with SSH depends on your application requirements. Even if you don't consider these, using certificates will be safer from a security perspective. Here is just a brief explanation of the use of certificates in SSH based on the latest version of PuTTY/cnPuTTY. Other client programs may be slightly different, but the general setup process is similar and can be simply referenced.
Before performing certificate authentication login, several concepts need to be explained:
CA: The certificate issuing authority is responsible for authenticating and issuing certificates for hosts or users.
User CA: refers to the key used by the CA organization to issue certificates to users.
Host CA: refers to the key used by the CA organization to issue certificates to the host.
The relevant CA is actually a key pair, which is only used for a specific role or purpose.
The user CA and host CA can be the same or different.
Certificate: A certificate is a certificate obtained by a CA digitally signing the host or user's public key, which represents the CA's recognition.
Key: refers to a private key file containing information that is not published to the public.
In order to distinguish the certificate authentication from the previous one, -cleanup clears the local cnPuTTY related data and deletes the previous user key. Clear the previous records in the authorized_keys file on the server and restore the initial state.
3. Log in using certificates - one-way, user certificate authentication
This is not a real concept here. Relatively speaking, in the following explanation, only the user's authentication is certificated, without changing the original public key authentication method for the host . In other words, only the user side has changed. Use this method to quickly migrate existing users from key authentication to certificate authentication. Only use the user AC to issue certificates to the user, and then the host adds trust to the user AC. After that, the user can access the server through the certificate and key. Here, the server is used as the CA, and the user CA key user_ca_root is generated to perform CA authentication operations on the user, and the authenticated certificate and key are used to log in. The process is as follows:
(1) Generate the user CA key pair user_ca_root
ssh-keygen -f user_ca_root -t rsa -b 4096 -C "user_ca_root@debian"
(2) Copy the user_ca_root.pub public key to the /etc/ssh/ directory
cp user_ca_root. pub /etc/ssh
(3). Add the user CA public key as a trusted key in the SSH server machine.
Add the following line of information to the SSH configuration file /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/user_ca_root.pub
Restart SSH service
sudo systemctl restart sshd
(4), obtain or regenerate the user key pair
(skip...)
(5), use the user CA key to sign the generated user public key
ssh-keygen -s user_ca_root -I jack@debain -n jack -V +52w id_rsa.pub
-s: Specify the user CA key used to issue the certificate
-I: Specify the certificate ID string
-n jack: Specify the subject included in the certificate, here represents the certificate pair Who is valid, can be multiple subjects separated by commas.
-V +52w: The validity period of the specified certificate is 52 weeks
id_rsa.pub: User public key
Note: For more detailed commands, please refer to the certificate-related command excerpts in ssh-keygen [Reprint]~~ The relevant instructions
will be generated after completion A file named id_rsa-cert.pub has "-cert" added to the public key. This file is the user's certificate file. Check the certificate information as follows:
//生成的用户证书信息
ssh-keygen -L -f id_rsa-cert.pub
id_rsa-cert.pub:
Type: [email protected] user certificate
Public key: RSA-CERT SHA256:llvMBwvGGiMMtFzk7hs4W8MnuU0ALi2V/P+UaWvHeBM
Signing CA: RSA SHA256:PrL+0LRAI2DWQB+D5/7Tu5UyoZZWnwziVlaSTbJPK5s
Key ID: "jack@debain"
Serial: 0
Valid: from 2022-11-22T19:09:00 to 2023-11-21T19:10:33
Principals:
jack
Critical Options: (none)
Extensions:
permit-X11-forwarding
permit-agent-forwarding
permit-port-forwarding
permit-pty
permit-user-rc It can be seen that the certificate is a user certificate, which contains specified extended information, including X11 forwarding, proxy forwarding, port forwarding, etc., as well as certificate ownership and validity period information.
(6) Obtain the user key and user certificate files locally, because only these two files are needed to log in using certificates in SSH. At this point, the server side where the user uses the certificate to authenticate and log in has been completed. What is left is the use of the local client. PuTTY/cnPuTTY can be used, or other client forms can be used.
(7) Because the key file format used by cnPuTTY is different from the key format generated by ssh-keygen, it cannot be used directly. So you need to use cnPuTTYgen for format conversion. Directly load the obtained private key file id_rsa in cnPuTTYgen, the prompt is as follows:
If you choose to save the private key here, you can save the key format in the format used by cnPuTTY. You can also select the "Key --->Key to add certificate" option, and then select the id_rsa-cert.pub user certificate you just obtained. The prompt is as follows:
Then select View "Certificate Information..." as follows:
You can see the relevant information in the certificate. The certificate type is user authentication key, and the validity period and related SHA256 value of the certificate are also displayed. The parameters specified when the user's CA key signed the user's public key are consistent with the information when viewing the certificate.
(8) Then you can use the converted private key file and certificate to log in to cnPuTTY. The settings here are the same as when logging in using the public key system. You also need to enter the user name in the data panel. The difference is that you need to specify both the private key file and the certificate file in the credentials panel.
Then save the session and click Open
Here again the warning message for the first connection appears. Do you still remember that before starting the certificate login related settings, a local -cleanup was performed to clean the local cnPuTTY related data, and everything was normal. Please note that this is a warning about host key information . After logging in
It is the same as logging in using the public key system, and logging in automatically using the certificate. The initial login display does not seem to be much different from logging in using a public key system. The event log information is as follows
//证书和密钥文件单独加载进行登陆的事件日志
2022-11-22 22:28:02 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-22 22:28:02 连接到 192.168.204.128 端口 22
2022-11-22 22:28:02 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-22 22:28:02 连接到 192.168.204.128
2022-11-22 22:28:02 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-22 22:28:02 使用SSH协议版本 2
2022-11-22 22:28:02 没有GSSAPI安全可用的上下文
2022-11-22 22:28:02 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-22 22:28:02 服务器也有ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-22 22:28:02 主机密钥指纹是：
2022-11-22 22:28:02 ssh-ed25519 255 SHA256:nLn7QFEy1Ru+S9ZgFPZbtAJoUT2k3Pfk816OsBxTzRg
2022-11-22 22:28:02 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-22 22:28:02 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-22 22:28:02 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-22 22:28:02 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-22 22:28:02 读取密钥文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack.ppk"
2022-11-22 22:28:02 正在读取证书文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\id_rsa-cert.pub"
2022-11-22 22:28:02 正在从带有证书的公钥发送 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\id_rsa-cert.pub"
2022-11-22 22:28:02 提供的公钥
2022-11-22 22:28:02 接受提供的公钥
2022-11-22 22:28:03 发送公钥签名
2022-11-22 22:28:03 授予访问权限
2022-11-22 22:28:03 打开主会话通道
2022-11-22 22:28:03 已开通主通道
2022-11-22 22:28:03 已分配 pty
2022-11-22 22:28:03 已启动 shell/command
Please note that in the event log, the relevant authentication information: it is still the same host ssh-ed25519 key fingerprint; local authentication reads the key file and certificate file, sends the relevant information in the certificate, and authenticates with the previous public key system There is a difference.
At this point, all operations for the user to log in in SSH using the certificate have been completed, and the user can continue other work as usual. During the login process, the user cannot feel the difference from the public key system, and it is only reflected in the log events. But the authentication implementation behind it is different. The above is to specify the private key and certificate files separately for login, because the certificate and private key can be stored as a document, and then use the cnPageant agent for identity authentication. cnPuTTY still needs to provide the login username, but not others. The log event output is as follows
//证书和密钥文件合并后使用使用cnPageant进行登陆的事件日志
2022-11-22 20:52:13 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-22 20:52:13 连接到 192.168.204.128 端口 22
2022-11-22 20:52:13 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-22 20:52:13 连接到 192.168.204.128
2022-11-22 20:52:13 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-22 20:52:13 使用SSH协议版本 2
2022-11-22 20:52:13 没有GSSAPI安全可用的上下文
2022-11-22 20:52:13 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-22 20:52:13 服务器也有ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-22 20:52:13 主机密钥指纹是：
2022-11-22 20:52:13 ssh-ed25519 255 SHA256:nLn7QFEy1Ru+S9ZgFPZbtAJoUT2k3Pfk816OsBxTzRg
2022-11-22 20:52:13 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-22 20:52:13 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-22 20:52:13 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-22 20:52:13 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-22 20:52:13 Pageant正在运行中,尝试请求密钥
2022-11-22 20:52:13 Pageant有 7 个SSH-2密钥
2022-11-22 20:52:13 尝试Pageant中的密钥 #0
2022-11-22 20:52:13 服务器拒绝了我们的密钥
2022-11-22 20:52:13 尝试Pageant中的密钥 #1
2022-11-22 20:52:13 服务器拒绝了我们的密钥
2022-11-22 20:52:13 尝试Pageant中的密钥 #2
2022-11-22 20:52:13 发送Pageant的回应
2022-11-22 20:52:13 授予访问权限
2022-11-22 20:52:13 打开主会话通道
2022-11-22 20:52:13 已开通主通道
2022-11-22 20:52:13 已分配 pty
2022-11-22 20:52:13 已启动 shell/command
This is the same as the log of using a proxy for authentication in public key authentication. There is no sense of certificate-related operations at all, but it does exist. If the certificate in the private key is removed, even if the correct user key is used, an error will be prompted, as follows
The log event output is as follows
//仅加载私钥，无对应证书的日志事件输出
2022-11-22 21:05:23 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-22 21:05:23 连接到 192.168.204.128 端口 22
2022-11-22 21:05:23 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-22 21:05:23 连接到 192.168.204.128
2022-11-22 21:05:23 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-22 21:05:23 使用SSH协议版本 2
2022-11-22 21:05:23 没有GSSAPI安全可用的上下文
2022-11-22 21:05:23 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-22 21:05:23 服务器也有ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-22 21:05:23 主机密钥指纹是：
2022-11-22 21:05:23 ssh-ed25519 255 SHA256:nLn7QFEy1Ru+S9ZgFPZbtAJoUT2k3Pfk816OsBxTzRg
2022-11-22 21:05:23 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-22 21:05:23 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-22 21:05:23 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-22 21:05:23 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-22 21:05:23 Pageant正在运行中,尝试请求密钥
2022-11-22 21:05:23 Pageant有 7 个SSH-2密钥
2022-11-22 21:05:23 尝试Pageant中的密钥 #0
2022-11-22 21:05:23 服务器拒绝了我们的密钥
2022-11-22 21:05:23 尝试Pageant中的密钥 #1
2022-11-22 21:05:23 服务器拒绝了我们的密钥
2022-11-22 21:05:23 尝试Pageant中的密钥 #2
2022-11-22 21:05:23 服务器拒绝了我们的密钥
2022-11-22 21:05:23 尝试Pageant中的密钥 #3
2022-11-22 21:05:23 服务器拒绝了我们的密钥
2022-11-22 21:05:23 尝试Pageant中的密钥 #4
2022-11-22 21:05:23 服务器拒绝了我们的密钥
2022-11-22 21:05:23 尝试Pageant中的密钥 #5
2022-11-22 21:05:23 远端发送断开消息 类型 2 (协议错误): "Too many authentication failures"
Because the local authentication failed to pass after multiple attempts, the server actively disconnected and sent an error type reminder message from the remote end. Local authentication attempts cannot be continued.
4. Log in using certificates - two-way, user/host certificate authentication
Normally, this method is used. At the same time, host and user authentication are certificated, and users and hosts establish mutual trust with the help of AC authority . The AC issues host certificates to trusted hosts through the host AC, and issues user certificates to trusted users through the user AC. The host adds trust to the user's AC, and the user adds trust to the host's AC. Then the host and user log in and access through the certificate. Here, the real host is used as the CA, and the host AC key host_ac and the user AC key user_ac are generated at the same time. Use the server's existing key to create the host certificate. The client uses the cnPuTTYgen program to generate the user's key and use it to create the user certificate. Then use the certificate in SSH to log in. Before starting, the SSH host key was regenerated for the server, so the host key fingerprint that appears may be different from the previous one, just to better distinguish the setting effect. In real applications, the host key will not be changed at will, and the relevant settings in the previous one-way certificate authentication will be cleared. The relevant process is omitted. Other processes are as follows:
(1) Use the key generation program in Git Bash locally to generate host_ca and user_ca keys
ssh-keygen -f host_ca -t rsa -b 4096 -C "host_ca@debian"
ssh-keygen -f user_ca -t ed25519 - C "user_ca@debian"
(2). Get the server public key from /etc/ssh to the local.
There may be multiple server public keys in the /etc/ssh folder. This time, select ssh_host_ecdsa_key.pub to the local to make the server certificate. .
(3) Make a server certificate
ssh-keygen -s host_ca -I host.debian -h -n debian,192.168.204.128 -V +52w ssh_host_ecdsa_key.pub
-s: Specify the host CA key used to issue the certificate
-I: Certificate ID string
-h: Specifies that the certificate type is a host certificate, not a user certificate.
-n debian,192.168.204.128: Specifies the subject included in the certificate, here refers to the valid host. It can be the domain name of the server, etc., or it can be multiple subjects separated by commas. There is no domain name resolution in this example, so simply specify the host name and host IP as the subject.
-V +52w: Specifies that the validity period of the certificate is 52 weeks.
ssh_host_ecdsa_key.pub: Server public key.
Note: For more detailed commands, please refer to the certificate-related command excerpts in ssh-keygen [Reprint]~~ After the relevant instructions
are completed, a file named ssh_host_ecdsa_key-cert.pub will be generated. Compared with the obtained server public key With the addition of "-cert", this file is the server's certificate file. Check the certificate information as follows:
//生成的服务器证书信息
$ ssh-keygen -L -f ssh_host_ecdsa_key-cert.pub
ssh_host_ecdsa_key-cert.pub:
Type: [email protected] host certificate
Public key: ECDSA-CERT SHA256:5HSN5rQKsCHwOnkT4CcXu8x/52wlJyPoKBFAwiLGDX0
Signing CA: RSA SHA256:nB5sQlbNaSsH1FJFVzl5kK1usZU2k/tUjYPnAFS4gi0 (using rsa-sha2-512)
Key ID: "host.debian"
Serial: 0
Valid: from 2022-11-24T22:58:00 to 2023-11-23T22:59:42
Principals:
debian
192.168.204.128
Critical Options: (none)
Extensions: (none)
It can be seen that the certificate type is host certificate, public key and CA related information, and also includes validity period, etc.
(4). Add a server certificate to the host.
Upload the server certificate ssh_host_ecdsa_key-cert.pub generated above to the server/etc/ssh directory, and set the corresponding permissions to 644.
Add the following line of information to the SSH configuration file /etc/ssh/sshd_config
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
Restart the SSH service
sudo systemctl restart sshd
At this time, the server has the ability to provide external certificates. You can perform simple tests using ssh -v on the server or local Git Bash . For example, the test on the server is as follows
You can already see the added server certificate information in the Server host certificate field.
(5) Generating user key and public key information
is different from one-way user certificate authentication in that cnPuTTYgen is used to generate user passwords.
(The key generation process is omitted...)
Because the key file generated by cnPuTTYgen is in a different format than OpenSSH. Therefore, when you want to obtain the user public key available for ssh-keygen, you can directly copy the public key information in the generation interface, or export the key generated by cnPuTTYgen to OpenSSH format, and then use ssh-keygen -y -f to extract the public key. Details The process is omitted.
Finally, the user key file jack_user.ppk and the public key file jack_user are obtained.
(6) Make a user certificate and use the user CA key user_ca to sign the user's public key file jack_user public key
ssh-keygen -s user_ca -I jack-cnPuTTY@debain -n jack -V +52w jack_user
-s: Specify User CA key used to issue certificates
-I: Specify the certificate ID string
-n jack: Specify the subject included in the certificate. This indicates who the certificate is valid for. It can be multiple subjects separated by commas.
-V +52w: The validity period of the specified certificate is 52 weeks
jack_user: User public key
Note : For more detailed commands, please refer to the certificate-related command excerpts in ssh-keygen [Reprint]~~ After the relevant instructions
are completed, a The file named jack_user-cert.pub has the "-cert" flag, indicating that this file is the generated user certificate file. View user certificate information as follows
//用户证书信息
$ ssh-keygen -L -f jack_user-cert.pub
jack_user-cert.pub:
Type: [email protected] user certificate
Public key: ECDSA-CERT SHA256:E0qQF+QG2wK8KOWw5nKjdK1MO2EtE2WfE1fut7QmY/k
Signing CA: ED25519 SHA256:mawy00rpUcYa3zuLeb3uZFBBP1HgqfVweQTVP+THKO0 (using ssh-ed25519)
Key ID: "jack-cnPuTTY@debain"
Serial: 0
Valid: from 2022-11-24T23:08:00 to 2023-11-23T23:09:23
Principals:
jack
Critical Options: (none)
Extensions:
permit-X11-forwarding
permit-agent-forwarding
permit-port-forwarding
permit-pty
permit-user-rc
The type of certificate is a user certificate, which also includes extensions of related user rights. However, the algorithm of the user CA key and the algorithm of the user key are different from the previous ones. You can also use cnPuTTYgen locally to try to bind the key and certificate. The process is omitted.
(7) Add trust to the new user CA on the server side.
The server can already provide certificates to the outside world, and users also have their own certificates and key files. But normal communication is still not possible because the server does not know the existence of the user CA that issues the certificate to the user. Therefore, the public key of the user CA needs to be submitted to the server and used as a trusted key.
Upload the user CA's public key user_ca.pub to the server's /etc/ssh/ directory and set the corresponding permissions to 644.
Add new user CA information in the SSH configuration file /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/user_ca.pub
Restart the SSH service
sudo systemctl restart sshd
(8) Add trust to the host CA on the client
The server can provide it to the outside world certificate, and the new user CA is known and trusted. There are also corresponding user certificates and private keys locally. Can I access the server normally?
This is of course possible, please refer to the related settings of " Use certificate for login - one-way, user certificate authentication ". The server can be accessed normally. But if this is the case, the certificate installation for the host is completely meaningless. Because if you log in now, the local client does not have the ability to verify the host certificate. In order to be able to locally verify the server's certificate, local trust in the host CA needs to be set up. There may be differences depending on the client used. Here we only introduce the relevant settings of PuTTY/cnPuTTY.
In the cnPuTTY host key panel, select "Configure host CAs" to open the dialog box as follows
The current interface is used to add local trust to the host CA. First, select the read file in the CA's public key record and select the host_ca.pub file. The fingerprint information of the host CA will be displayed in the lower line. Then select the CA's credibility and enter a valid host expression to specify the range in which this host CA is used. In this example, you choose to enter * here, which means any range. Then specify the name of the CA. This is for the convenience of user identification and is also displayed in log events. Then click Save to record the relevant information normally, and finally click Finish. The settings here are global and valid for all sessions.
(9) Client login
Now you can log in to the client. You also need to specify the user name in the data panel, specify the user private key and certificate file in the credentials panel, and then select Open.
A magical scene happened. The login was completed automatically without any additional warning. After logging in as follows
Do you still remember the warning message that I specially reminded you to pay attention to before? ? There seems to be nothing here to alert the user. In the end what happened? ? We can check the event log, which is recorded as follows
//双向证书认证登陆的事件日志输出
2022-11-24 23:27:32 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-24 23:27:32 连接到 192.168.204.128 端口 22
2022-11-24 23:27:32 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-24 23:27:32 连接到 192.168.204.128
2022-11-24 23:27:32 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-24 23:27:32 使用SSH协议版本 2
2022-11-24 23:27:32 没有GSSAPI安全可用的上下文
2022-11-24 23:27:32 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-24 23:27:32 服务器也有ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-24 23:27:32 主机密钥指纹是：
2022-11-24 23:27:32 [email protected] 256 SHA256:5HSN5rQKsCHwOnkT4CcXu8x/52wlJyPoKBFAwiLGDX0
2022-11-24 23:27:32 主机密钥是一个证书.Hash包含证书:
2022-11-24 23:27:32 [email protected] 256 SHA256:CFc3/1SuOxoqik/RnX5SU94mZn1FfX8scImCkUW3sdo
2022-11-24 23:27:32 证书ID字符串为："host.debian"
2022-11-24 23:27:32 证书颁发机构的指纹：
2022-11-24 23:27:32 ssh-rsa 4096 SHA256:nB5sQlbNaSsH1FJFVzl5kK1usZU2k/tUjYPnAFS4gi0
2022-11-24 23:27:32 证书颁发机构匹配 'host_ca_test'
2022-11-24 23:27:32 接受的证书
2022-11-24 23:27:32 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-24 23:27:32 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-24 23:27:32 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-24 23:27:32 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-24 23:27:32 读取密钥文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user.ppk"
2022-11-24 23:27:32 正在读取证书文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user-cert.pub"
2022-11-24 23:27:32 正在从带有证书的公钥发送 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user-cert.pub"
2022-11-24 23:27:32 提供的公钥
2022-11-24 23:27:32 接受提供的公钥
2022-11-24 23:27:32 发送公钥签名
2022-11-24 23:27:32 授予访问权限
2022-11-24 23:27:32 打开主会话通道
2022-11-24 23:27:33 已开通主通道
2022-11-24 23:27:33 已分配 pty
2022-11-24 23:27:33 已启动 shell/command
Please note in the event log, the relevant authentication information: the server gave the host key fingerprint in the form of a certificate, the fingerprint information when the certificate was included, and the fingerprint information of the certificate authority. The certificate ID string is what we specified when issuing the server certificate. "host_ca_test" appears later, which is the name specified when setting up a trusted certificate authority locally. Then it prompts "Accepted Certificate". This completes the verification of the host through the certificate. The subsequent process is consistent with the process of one-way user certificate verification. [The currently displayed information needs to be corrected and will be fixed in the next version of cnPuTTY]
In fact, if you are careful, you should have noticed the changes in the fingerprint information when you used cnPuTTYgen to try to merge the key and certificate. In order to explain the relevant changes more clearly here, the key corresponding to ssh_host_ecdsa_key.pub when making the server certificate is taken locally and merged. After loading the key into cnPuTTYgen, it prompts for conversion, then as follows
You can see the fingerprint information from the server host key, and then add the certificate file ssh_host_ecdsa_key-cert.pub to the key as follows
After importing the certificate, the fingerprint changed slightly and started with [email protected] , but the fingerprint SHA256 value was the same as the previous server key fingerprint. Then check the certificate information as follows
This contains the fingerprint information of the host CA that signed the server's public key , and there is also fingerprint information that also contains the certificate . Now go back and check the event log, add a locally trusted certificate authority, check the generated server certificate and verify whether the server certificate is valid. The corresponding fingerprint information is consistent. Of course, the same is true for user certificate-related verification.
In addition to specifying the key and certificate files separately for loading and use, you can also merge the two and use the identity agent program for verification. The specific process is omitted. At this point, the operation of using the certificate for two-way authentication login has been completed. You can log in normally and perform other operations. By viewing the event log, you can clearly see the differences in various verification processes. Even if a certificate is used, there is a difference between one-way authentication and two-way authentication on the user side.
To learn more about the process of mutual certificate verification, more verifications can be done. First try to use the previous user certificate or key locally. When replacing the user key or certificate individually , the following prompt will appear:
The event log information is as follows
//用户密钥或者证书被替换后
2022-11-25 13:47:51 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-25 13:47:51 连接到 192.168.204.128 端口 22
2022-11-25 13:47:51 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-25 13:47:51 连接到 192.168.204.128
2022-11-25 13:47:51 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-25 13:47:51 使用SSH协议版本 2
2022-11-25 13:47:51 没有GSSAPI安全可用的上下文
2022-11-25 13:47:51 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-25 13:47:51 服务器也有ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-25 13:47:51 主机密钥指纹是：
2022-11-25 13:47:51 [email protected] 256 SHA256:5HSN5rQKsCHwOnkT4CcXu8x/52wlJyPoKBFAwiLGDX0
2022-11-25 13:47:51 主机密钥是一个证书.Hash包含证书:
2022-11-25 13:47:51 [email protected] 256 SHA256:CFc3/1SuOxoqik/RnX5SU94mZn1FfX8scImCkUW3sdo
2022-11-25 13:47:51 证书ID字符串为："host.debian"
2022-11-25 13:47:51 证书颁发机构的指纹：
2022-11-25 13:47:51 ssh-rsa 4096 SHA256:nB5sQlbNaSsH1FJFVzl5kK1usZU2k/tUjYPnAFS4gi0
2022-11-25 13:47:51 证书颁发机构匹配 'host_ca_test'
2022-11-25 13:47:51 接受的证书
2022-11-25 13:47:51 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-25 13:47:51 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-25 13:47:51 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-25 13:47:51 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-25 13:47:51 读取密钥文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user.ppk"
2022-11-25 13:47:51 正在读取证书文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\old\id_rsa-cert.pub"
2022-11-25 13:47:51 不替代证书 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\old\id_rsa-cert.pub" 对于公钥：base public key does not match certificate
2022-11-25 13:47:51 提供的公钥
2022-11-25 13:47:51 服务器拒绝了我们的密钥
2022-11-25 13:49:51 远程端意外关闭网络连接
From the above information [the currently displayed information needs to be corrected, it will be fixed in the next version of cnPuTTY]. It can be seen that the local verification of the host is still completed through the certificate method, but the local certificate and key do not match. In the end The server rejected us and closed the connection with us without receiving a password input within the specified time. In fact, when using cnPuTTYgen to merge certificates and keys, as long as the two do not match, an error will be reported and the merge cannot be done. In addition, to access the server through certificate method, you need to use the user key and user certificate locally, whether you use PuTTY/cnPuTTY or other SSH commands to connect. Local verification of both the key and the certificate fails, and the server certainly has no reason to accept it.
Now try changing the contents of the certificate issued to the server and see what happens. Only the generation parameters of the server certificate have been changed here, and other settings have not been changed . The detailed process is omitted. No changes are made to the client, just log in directly. You will receive the following warning message
Here is a warning message about CA certification [the current interface contains information that needs to be corrected and will be fixed in the next version of cnPuTTY] . The host key fingerprint is provided in the form of a certificate. This is completely different from the previous warning message that reminded special attention. . Then check the event log to see what happened
//修改服务器证书的生成参数后的事件日志输出
2022-11-25 14:14:52 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-25 14:14:52 连接到 192.168.204.128 端口 22
2022-11-25 14:14:52 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-25 14:14:52 连接到 192.168.204.128
2022-11-25 14:14:52 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-25 14:14:52 使用SSH协议版本 2
2022-11-25 14:14:52 没有GSSAPI安全可用的上下文
2022-11-25 14:14:52 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-25 14:14:52 服务器也有ssh-ed25519/ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-25 14:14:52 主机密钥指纹是：
2022-11-25 14:14:52 [email protected] 256 SHA256:5HSN5rQKsCHwOnkT4CcXu8x/52wlJyPoKBFAwiLGDX0
2022-11-25 14:14:52 主机密钥是一个证书.Hash包含证书:
2022-11-25 14:14:52 [email protected] 256 SHA256:nZnuv4ziNaYsT6Ye0x39QaECkpQUEnk7EvmxUgLWb6Q
2022-11-25 14:14:52 证书ID字符串为："host.debian"
2022-11-25 14:14:52 证书颁发机构的指纹：
2022-11-25 14:14:52 ssh-rsa 4096 SHA256:nB5sQlbNaSsH1FJFVzl5kK1usZU2k/tUjYPnAFS4gi0
2022-11-25 14:14:52 证书颁发机构匹配 'host_ca_test'
2022-11-25 14:14:52 被拒绝的主机密钥证书：Certificate's hostname list ["debian"] does not contain expected hostname "192.168.204.128"
2022-11-25 14:15:30 无论任何时候,都接受经过认证的主机密钥缓存
2022-11-25 14:15:30 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-25 14:15:30 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-25 14:15:30 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-25 14:15:30 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-25 14:15:30 读取密钥文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user.ppk"
2022-11-25 14:15:30 正在读取证书文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user-cert.pub"
2022-11-25 14:15:30 正在从带有证书的公钥发送 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user-cert.pub"
2022-11-25 14:15:30 提供的公钥
2022-11-25 14:15:30 接受提供的公钥
2022-11-25 14:15:30 发送公钥签名
2022-11-25 14:15:30 授予访问权限
2022-11-25 14:15:30 打开主会话通道
2022-11-25 14:15:31 已开通主通道
2022-11-25 14:15:31 已分配 pty
2022-11-25 14:15:31 已启动 shell/command
Please note that in the event log, the relevant authentication information: [The current interface contains information that needs to be corrected, which will be fixed in the next version of cnPuTTY] The verification process of the corresponding server certificate is the same as before, the difference is that the "Accepted Certificate" was prompted before, and The modified prompt is "Rejected Host Key Certificate" because the currently accessed 192.168.204.128 is not in the host name list of the certificate. For local, the server's certificate is indeed issued by a trusted issuing authority and matches the certificate authority, but the current server is not recognized by this certificate, although this certificate has been installed on the server. It prompts "At any time, authenticated host key caches are accepted", and then the client provides verification information in the form of a certificate.
The server certificate is recognized locally, but the server is not recognized by the certificate, or it is not the subject of the certificate. The host certificate was accepted and verified locally and the problem was discovered. When verifying the trust of the server certificate, the applicability of the certificate to the server is also verified. The command "ssh-keygen -s host_ca -I host.debian -h -n debian -V +52w ssh_host_ecdsa_key.pub" is used here to generate the certificate. The subsequent process is consistent with the one-way user certificate authentication method. So what would happen if the issuing host CA of the server certificate is really changed, but the old host CA information is still used locally ? ? Here, Git Bash is used to generate the other_ca key, and "ssh-keygen -s other_ca -I host.debian -h -n debian,192.168.204.128 -V +52w ssh_host_ecdsa_key.pub" is used to issue the same host public key ssh_host_ecdsa_key.pub The certificate is then installed on the server to make it effective. The old host_ca.pub host CA is trusted locally. The detailed process is omitted. The newly generated host certificate is as follows
//新的主机证书
$ ssh-keygen -L -f ssh_host_ecdsa_key-cert.pub
ssh_host_ecdsa_key-cert.pub:
Type: [email protected] host certificate
Public key: ECDSA-CERT SHA256:5HSN5rQKsCHwOnkT4CcXu8x/52wlJyPoKBFAwiLGDX0
Signing CA: RSA SHA256:z1xz9eAC+NlYORkGYwZmc3rDRxf87FkHtC+mkFq2EKA (using rsa-sha2-512)
Key ID: "host.debian"
Serial: 0
Valid: from 2022-11-25T15:00:00 to 2023-11-24T15:01:34
Principals:
debian
192.168.204.128
Critical Options: (none)
Extensions: (none)
Then install it on the server and make it work. When logging in using the local unmodified client, no warning message pops up. The event log is as follows:
//重新生成主机AC，客户端AC被改变
2022-11-25 15:07:51 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-25 15:07:51 连接到 192.168.204.128 端口 22
2022-11-25 15:07:51 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-25 15:07:51 连接到 192.168.204.128
2022-11-25 15:07:51 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-25 15:07:51 使用SSH协议版本 2
2022-11-25 15:07:51 没有GSSAPI安全可用的上下文
2022-11-25 15:07:51 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-25 15:07:51 服务器也有ssh-ed25519/ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-25 15:07:51 主机密钥指纹是：
2022-11-25 15:07:51 [email protected] 256 SHA256:5HSN5rQKsCHwOnkT4CcXu8x/52wlJyPoKBFAwiLGDX0
2022-11-25 15:07:51 主机密钥是一个证书.Hash包含证书:
2022-11-25 15:07:51 [email protected] 256 SHA256:PG3e4cWrOXHZLo2SsdiuLjPhcdpCErfzpogxXgdQBTQ
2022-11-25 15:07:51 证书ID字符串为："host.debian"
2022-11-25 15:07:51 证书颁发机构的指纹：
2022-11-25 15:07:51 ssh-rsa 4096 SHA256:z1xz9eAC+NlYORkGYwZmc3rDRxf87FkHtC+mkFq2EKA
2022-11-25 15:07:51 被拒绝的主机密钥证书：证书颁发机构不受信任
2022-11-25 15:07:51 无论任何时候,都接受经过认证的主机密钥缓存
2022-11-25 15:07:51 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-25 15:07:51 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-25 15:07:51 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-25 15:07:51 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-25 15:07:51 读取密钥文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user.ppk"
2022-11-25 15:07:51 正在读取证书文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user-cert.pub"
2022-11-25 15:07:51 正在从带有证书的公钥发送 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user-cert.pub"
2022-11-25 15:07:51 提供的公钥
2022-11-25 15:07:51 接受提供的公钥
2022-11-25 15:07:51 发送公钥签名
2022-11-25 15:07:51 授予访问权限
2022-11-25 15:07:51 打开主会话通道
2022-11-25 15:07:51 已开通主通道
2022-11-25 15:07:51 已分配 pty
2022-11-25 15:07:51 已启动 shell/command
Please note that in the event log, the relevant authentication information: [The current interface contains information that needs to be corrected, which will be fixed in the next version of cnPuTTY] The key fingerprint of the host given in the form of a certificate has not changed, because the public key used when making the certificate is the same one. However, the host AC and the fingerprint information containing the certificate have changed, and it directly prompts "The certificate issuing authority is not trusted." Before, it was just that the server certificate did not match the host, but now the certificate issuing authority is not trusted locally. It prompts "At any time, authenticated host key caches are accepted", and then the client provides verification information in the form of a certificate.
What happens if the host's key changes after logging in using a certificate? Next to verify, after completing all normal settings, regenerate the host key. The prompt when logging in using cnPuTTY is as follows:
A common host key warning appeared again, check the event log as follows
//证书登陆下，重新生成主机密钥后
2022-11-30 13:44:17 查找主机 "192.168.204.128" 来自 SSH连接
2022-11-30 13:44:17 连接到 192.168.204.128 端口 22
2022-11-30 13:44:17 我们声明的版本：SSH-2.0-PuTTY_Release_0.78
2022-11-30 13:44:17 连接到 192.168.204.128
2022-11-30 13:44:17 远程版本：SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
2022-11-30 13:44:17 使用SSH协议版本 2
2022-11-30 13:44:17 没有GSSAPI安全可用的上下文
2022-11-30 13:44:17 执行 ECDH key exchange with curve Curve25519,使用哈希 SHA-256 (unaccelerated)
2022-11-30 13:44:17 服务器也有ecdsa-sha2-nistp256/rsa-sha2-512/rsa-sha2-256/ssh-rsa主机密钥,但我们未存储它们
2022-11-30 13:44:17 主机密钥指纹是：
2022-11-30 13:44:17 ssh-ed25519 255 SHA256:1Rg+jmbbVCBjcL22CFRfbpNN2JcSG12ZA8exiMj5d4Q
2022-11-30 13:45:01 已初始化 AES-256 SDCTR (unaccelerated) 出站加密
2022-11-30 13:45:01 已初始化 HMAC-SHA-256 (unaccelerated) 出站MAC算法
2022-11-30 13:45:01 已初始化 AES-256 SDCTR (unaccelerated) 入站加密
2022-11-30 13:45:01 已初始化 HMAC-SHA-256 (unaccelerated) 入站MAC算法
2022-11-30 13:45:01 读取密钥文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user.ppk"
2022-11-30 13:45:01 正在读取证书文件 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user-cert.pub"
2022-11-30 13:45:02 正在从带有证书的公钥发送 "C:\Users\Administrator\Desktop\cnPuTTY 0.78.0.2_32-bit x86\jack_user-cert.pub"
2022-11-30 13:45:02 提供的公钥
2022-11-30 13:45:02 接受提供的公钥
2022-11-30 13:45:02 发送公钥签名
2022-11-30 13:45:02 授予访问权限
2022-11-30 13:45:02 打开主会话通道
2022-11-30 13:45:02 已开通主通道
2022-11-30 13:45:02 已分配 pty
2022-11-30 13:45:02 已启动 shell/command
It can be seen that there is no information related to the host certificate in the event log, and it is similar to the one-way authentication of the certificate. When the host CA did not match before or the certificate generation method was changed, the event log showed that a CA-certified certificate was received, and it was prompted "At any time, the certified host key cache is accepted . " Of course, if you change the relevant settings of the server user CA, the verification of the corresponding user will return to the previous key or password verification .
Changing the certificate issuance method and changing the host CA used for authentication will cause problems with server certificate authentication. The host key certified by a third party is provided to the client in the form of a certificate, and the client will accept it. The subsequent authentication process is the same as the verification of one-way user certificate login, because the server recognizes the user CA, and there is no problem in one-way user certificate login itself. Whether you can be prompted for "Accepted Certificate" depends on whether the correct server certificate is issued and installed. If the certificate settings remain unchanged and the server host key changes, the verification of the corresponding host will return to the original key verification. Through these changes, we also have a general understanding of the impact of related changes on certificate verification login.
In fact, the server has not added the relevant information of the host CA until now. In this example, it does not affect the verification and use of the certificate. Upload the host_ca.pub file of the host CA to the server, add information to the /.ssh/known_hosts file, and then add @cert-authority * at the beginning of the line to indicate that the current record is the certificate issuing authority CA, followed by the host name field, star No. indicates matching all, domain name information can also be specified, and can contain multiple contents. This method is only applicable to specifying the host CA for the current user. If global settings are required, the administrator needs to add information to the /etc/ssh/ssh_known_hosts file. After adding, test the SSH connection as follows:
//服务器安装主机AC公钥后的测试
$ ssh -v [email protected]
OpenSSH_7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2u 20 Dec 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.204.128 [192.168.204.128] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/jack/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jack/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jack/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jack/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jack/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jack/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jack/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jack/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u7
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u7 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.204.128:22 as 'jack'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: [email protected]
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host certificate: [email protected] SHA256:5HSN5rQKsCHwOnkT4CcXu8x/52wlJyPoKBFAwiLGDX0, serial 0 ID "host.debian" CA ssh-rsa SHA256:nB5sQlbNaSsH1FJFVzl5kK1usZU2k/tUjYPnAFS4gi0 valid from 2022-11-24T22:58:00 to 2023-11-23T22:59:42
debug1: Host '192.168.204.128' is known and matches the ECDSA-CERT host certificate.
debug1: Found CA key in /home/jack/.ssh/known_hosts:1
debug1: rekey after 134217728 blocksThe server has added a host CA and will trust other hosts certified by the same host CA. Adding a trusted certificate authority in PuTTY/cnPuTTY is similar to modifying and adding known_hosts. If the client uses other Linux hosts or clients like Git Bash/MSYS2, you need to use a similar method to add information to known_hosts to recognize the host CA. The support and use of certificates can also be global or only set to be effective for certain users. The setting process is similar, but the file location needs to be modified to be different.
About certificate revocation
During the complete cycle of using the certificate, you can simply rely on the validity period of the certificate to invalidate the certificate, or you can actively revoke the certificate. By adding the public key to the revoked_Keys file and adding the following information in sshd_config:
RevokedKeys /etc/ssh/revoked_keys
Note that if this file is not readable, public key authentication will be denied to all users.
To test whether it has been revoked, you can query whether the corresponding public key exists in the revocation list. Use the command as follows:
ssh keygen-Qf /etc/ssh/revoked_keys ~/.ssh/id_rsa.pub
The client can revoke the CA certificate by changing the cert-authority certificate mark directive to the revoke directive in the known_hosts file . For PuTTY/cnPuTTY, the trusted certificate issuing authority information is directly deleted to revoke trust in the host CA.
In all the examples described, there are actually no strict restrictions on key generation, who acts as the CA, which key algorithm is used, and the public key selection for generating the certificate. It is very important to ensure the security of each key, especially the security of the CA key when using certificates for verification.
[Explanation on error messages]
One of the purposes of this document is to "collect some cnPuTTY error messages and use them to modify cnPuTTY .Some areas that may need correction have been marked during the description process. In addition to these, the information also collected includes: 1 correction to the display interface, 4 additions to the agent interface information, 10 modifications to the warning information, 3 network error messages, the printing information of the first-class session interface is garbled and needs to be corrected, and many The event log information display and description are vague, the CA warning information interface is omitted or the description is vague, etc. These are mainly reflected in the interface display and have no impact on the use of functions. At least I didn't experience any functional impact.
The current modifications to PuTTY are mainly focused on the display language, which has been done so far. The only modification belonging to cnPuTTY is that in a specific log mode, the log record content is garbled when outputting Chinese . The relevant content collected this time will be revised next time. Here is the same reminder: No one can be sure or guarantee that cnPuTTY will be released and updated simultaneously with subsequent updates of PuTTY, nor can it be guaranteed or guaranteed that cnPuTTY's own version will be subsequently updated or patched. Maybe the release and update of cnPuTTY is only a one-time event. So you don't need to wait for anything, maybe PuTTY or other alternative methods will be a better choice.
More detailed error messages are not the focus of this release, so they are omitted here. If you use cnPuTTY, if you see some ambiguous descriptions, that’s probably it. Maybe you won’t encounter some of them. Or if it's something I haven't encountered yet, if you would like to let me know, I'd be happy to accept it.
[Disclaimer] All related content and related releases here follow the same guidelines, without providing any guarantee or assuming any responsibility. There is no guarantee that it can be completely reproduced in your practice. You should fully verify your needs and settings to avoid unnecessary trouble. For other related content, please refer to the corresponding license and instructions.
[Reference information] For other information, please refer to the following link or the corresponding original link:
Public key certificate authentication system used in SSH [Reprint]~~
Excerpts of certificate-related commands in ssh-keygen [Reprint]~~
ssh-keygen Relevant descriptions about the certificate part [Reprint]~~
Using OpenSSH Certificate Authentication
Welcome to the SSH Academy
and other related content.