PuTTY/cnPuTTY在SSH中的使用及SSH证书认证的简单说明~~

       2022-10-29 PuTTY官方正式发布 0.78 released。此次更新最重大的变化就是支持OpenSSH证书，用于用户身份验证密钥和主机密钥。为此cnPuTTY也进行了同步更新，相关内容请查看发布信息。

       在对cnPuTTY进行更新的过程中，只是简单的进行了CA密钥生成以及对测试公钥进行证书签发，用于加载到cnPuTTYgen进行密钥与证书的添加删除功能测试和cnPageant的证书相关功能测试。没有更进一步去探究相关功能在PuTTY/cnPuTTY的使用。最近在查看SSH使用证书进行登陆的相关信息中发现了一些很奇怪的问题：通过搜索相关内容，发现关于“在SSH中使用证书进行登陆”的绝大部分文档中都是描述使用“公钥认证”，把公钥或者私钥简单当做证书认证去描述相关问题。更有甚者，把PuTTYgen生成的公钥添加到服务器定义为“公钥登陆”；把服务器上用户生成的id_rsa密钥拿下来用来登陆定义为“私钥登陆”。或许是搜索方式有问题，只看到了这些相关信息？这些定义是不正确的。密钥或者公钥并不等同于证书，至少在相关协议说明中并不相等。又或许是每个人的理解不同，如何如何这要看读者自己了！！

       其实上述操作本质上就是通过公钥系统进行认证，只是所使用的公钥或者私钥的来源或生成方法有所不同，不能被称为“SSH下的证书登陆”。一般证书系统中会存在签发机构以及证书签发的动作。在上述相关的描述中并没有出现签发以及证书文件。另外在SSH证书相关协议中，明确定义了相关证书的数据格式及扩展，请参考：在SSH中使用的公钥证书认证系统 [转载]~~。上述操作均未涉及相关协议及数据，所有不能认定为是正确的，至少不能认为是“SSH下的证书登陆”。在查询到的其他相关说明中“阮一峰的网络日志 — SSH 证书登录教程”、“随风逐叶 — SSH 证书登录”这两篇内容是真实的对SSH中证书的使用进行了较为详尽的描述，极具参考性。

       本文档主要目的是：对PuTTY/cnPuTTY进行证书认证登陆的使用说明，同时描述了PuTTY/cnPuTTY在其他方式下的登陆，并提供事件日志的输出进行对比参考。另外就是收集一些cnPuTTY的错误信息，用来修改cnPuTTY。在记录过程中可能会涉及到三个不同位置的密钥生成程序，分别是虚拟机中的Debian密钥生成、真实主机中Git Bash的密钥生成以及cnPuTTY中的密钥生成程序。密钥/公钥的来源也可能来自不同的位置，具体使用来源以描述信息为准。

       SSH服务器的相关基础设置不在讨论列，这里的前提是已经存在一个可用的SSH服务器，并且允许使用密码或者密钥进行正常登陆访问。登陆的客户端选择cnPuTTY，当然PuTTY也是一样的，只是为修改收集一些错误信息而已。

一、使用密码进行登陆

       正如你所了解的，这个好像没什么可用描述的。直接输入IP地址，端口号默认，然后保存选择打开。会弹出首次连接的的警告信息，然后选择接受。

 

 输入账号密码即可登陆，登陆后

 事件日志记录：

//使用账户密码进行登陆的事件日志
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

请注意在事件日志中，相关认证信息：主机ssh-ed25519密钥指纹；本地发送密码提供认证。

二、使用公钥认证系统

       具体的相关过程可以参考其他文档，也可以参考cnPuTTY内置手册第8.3 准备公钥认证章节的相关内容。这里使用cnPuTTYgen程序生成相关密钥，用你最趁手的方式将公钥信息保存到登陆用户目录下/.ssh/authorized_keys文件当中。同样也可以使用服务器上存在的用户密钥相关信息。

在数据面板输入用户名

 在凭证面板指定用户密钥文件

然后保存选择打开，即可自动登陆。因为之前登陆过，已保存了主机密钥，所有没有警告提醒。登陆后

 

 事件日志记录：

//使用公钥系统进行登陆的事件日志——直接指定密钥文件
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

请注意在事件日志中，相关认证信息：主机ssh-ed25519密钥指纹依然存在；本地认证从之前的发送密码变更为读取密钥文件，并发送公钥的相关信息到服务器进行相关认证。

       当然也可以使用cnPageant身份代理程序来管理密钥进行登陆。其他设置不变，只是密钥加载到代理程序当中使用。事件日志如下：

//使用公钥系统进行登陆的事件日志——使用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

请注意在事件日志中，相关认证信息：主机ssh-ed25519密钥指纹依然存在；本地认证使用cnPageant身份代理提供密钥信息，当代理中存在多个密钥时，会自动匹配。

      至此，常规的SSH登陆认证操作已经介绍完毕，从上面的过程可以看出，确实是不存在证书的相关信息。在介绍SSH中证书认证之前，首先要讨论一些额外的问题：为什么要使用证书？？如果上面的这些已经满足使用要求，那有需要使用证书吗？？

       对于常规的使用，以上就可以满足基本要求，但随着主机或者用户数量增加时，授权的密钥文件激增，使其难以管理。如果使用证书，只要用服务器信任的用户CA对新增加的用户进行证书签发，用户就可以使用证书和密钥进行登陆，服务器不需要做任何更改。密钥的生成和使用是没有用户属性和时间属性的，只要这个密钥存在，任何人获得后都可以使用，并且只要公钥信息没有从服务器删除，这个密钥将永久有效，但密钥是否安全可靠无法保障。如果使用证书，可以对用户身份进行绑定，并且证书是可以指定有效期的，可以指定一个短期有效的证书，比如1小时或者一个月等。在到期后自动失效，服务器不需要做任何更改。另外正如SSH证书认证协议描述的那样，证书可以包含多种数据，可以对SSH登陆做出限制，比如禁止PTY分配或者端口转发、禁用X11转发等等。其它使用证书的优势请自行了解。是否需要在SSH中使用证书，这取决于你的应用需求。就算不考虑这些，从安全性来说使用证书会更加安全。这里只是结合最新版本的PuTTY/cnPuTTY对SSH中证书的使用进行简单的说明，其他客户端程序可能略有差异，但大致的设置流程是类似的，也可以简单参考。

在进行证书认证登陆之前，需要说明几个概念：
CA：即证书颁发机构，负责对主机或者用户进行认证和证书签发。
      用户CA：是指CA机构用于对用户进行证书签发的密钥。
      主机CA：是指CA机构用于对主机进行证书签发的密钥。
相关CA其实本质是一个密钥对，只是用于特定的作用或者目的。
用户CA和主机CA可以是同一个，也可以是不同的。
证书：证书是CA对主机或者用户公钥进行数字签名后的凭证，代表CA的认可。
密钥：指包含不对外公布信息的私钥文件。

      这为了区别证书认证与之前的不同，-cleanup清除一下本地cnPuTTY的相关数据，删除之前的用户密钥。服务器上清除之前authorized_keys文件中的记录，还原初始状态。

三、使用证书进行登陆——单向，用户证书认证 

       这里不是一个真实存在的概念。只是相对来说在接下来的说明当中，只对用户的认证进行了证书化，而不改变对主机原有的公钥认证方式。也就是说只有用户侧发生了变化。使用这种方法可以快速的迁移现有用户从密钥认证到证书认证。仅使用用户AC对用户进行证书签发，然后主机添加对用户AC的信任，之后用户就可以通过证书及密钥访问服务器。在这里使用服务器作为CA，并生成用户CA密钥user_ca_root来对用户进行CA认证操作，并使用认证后的证书及密钥进行登陆。过程如下：

(1)、生成用户CA密钥对user_ca_root
       ssh-keygen -f user_ca_root -t rsa -b 4096 -C "user_ca_root@debian"
(2)、复制user_ca_root.pub公钥到/etc/ssh/目录
       cp user_ca_root.pub  /etc/ssh
(3)、在SSH服务器机器中添加用户CA公钥作为可信密钥
       在SSH配置文件/etc/ssh/sshd_config中添加如下一行信息
       TrustedUserCAKeys /etc/ssh/user_ca_root.pub
       重新启动SSH服务
       sudo systemctl restart sshd
(4)、获取或者重新生成用户密钥对
        (略过...)
(5)、使用用户CA密钥对生成的用户公钥进行签名
       ssh-keygen -s user_ca_root -I jack@debain -n jack -V +52w id_rsa.pub
           -s：指定用来签发证书的用户CA密钥
           -I：指定证书ID字符串
           -n jack：指定包含在证书中的主体，这里表示证书对谁有效，可以是逗号分隔的多个主体。
           -V +52w：指定证书的有效期为52周
           id_rsa.pub：用户公钥
       注：更多详细的命令请参考ssh-keygen中与证书有关的命令摘录[转载]~~的相关说明
完成后会生成一个名为id_rsa-cert.pub的文件，与公钥相比多了“-cert”，这个文件就是用户的证书文件。查看证书信息如下：

//生成的用户证书信息
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

       可以看出证书是一个用户证书，其中包含了指定的扩展信息，包括X11转发，代理转发，端口转发等，也包含证书所属及有效期信息。
(6)、获取用户密钥、用户证书文件到本地，因为在SSH中使用证书登陆仅需要这两个文件。到这里用户使用证书进行认证登陆的服务器端已经完成，剩下的就是本地客户端的使用，可以使用PuTTY/cnPuTTY，也可以使用其他客户端形式。
(7)、因为cnPuTTY使用的密钥文件格式与ssh-keygen生成的密钥格式不一样，无法直接使用。所以需要使用cnPuTTYgen进行格式转换。在cnPuTTYgen直接加载获得的私钥文件id_rsa，提示如下：

       这里选择保存私钥，就可以将密钥格式保存为cnPuTTY使用的格式。也可以选择“密钥--->将证书添加的密钥”选项，然后选择刚才一同获得的id_rsa-cert.pub用户证书，提示如下：

然后选择查看“证书信息...”，如下：

 

        可以看到证书中的相关信息，证书类型为用户认证密钥，同时也展示了证书的有效期和相关SHA256值。与用户CA密钥对用户的公钥进行签名时指定的参数和查看的证书时的信息一致。
(8)、然后可以使用转换过的私钥文件和证书在cnPuTTY中进行登陆。这里与使用公钥系统进行登陆时的设置一样，同样需要在数据面板输入用户名，不同的是在凭证面板需要同时指定私钥文件和证书文件。

 然后保存会话，点击打开

       这里再次出现首次连接的的警告信息。还记得吗，在开始证书登陆相关设置前，本地进行了一次-cleanup，清理的本地的cnPuTTY相关数据，所有是正常的。请留意这里是主机密钥信息的相关警告信息。登陆后

       同样与使用公钥系统进行登陆是一样的，使用证书也是自动登陆的。在初次登陆的显示当中与使用公钥系统进行登陆看起来似乎没太多不同。事件日志的信息如下

//证书和密钥文件单独加载进行登陆的事件日志
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

请注意在事件日志中，相关认证信息：依旧是相同的主机ssh-ed25519密钥指纹；本地认证读取了密钥文件和证书文件，发送了证书中的相关信息，跟之前的公钥系统认证有所差异。

       到这里已经完成用户使用证书在SSH中登陆的所有操作，用户可以像平常一样继续其他工作。在登陆过程中，用户是感觉不到与公钥系统的差异的，只是在日志事件中有所体现。但背后的认证实现是不相同的。上面是单独指定私钥和证书文件进行登陆的，因为证书和私钥可以存储为一个文档，然后使用cnPageant代理进行身份认证。cnPuTTY依旧需要提供登陆的用户名，其他则不需要。日志事件输出如下

//证书和密钥文件合并后使用使用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

       这里与公钥认证中使用代理进行认证的日志一样，根本感知不到证书相关的操作，但它确实是存在的。如果剔除私钥中的证书，即使是使用正确的用户密钥，也会提示出错，如下

日志事件输出如下

//仅加载私钥，无对应证书的日志事件输出
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"

       由于本地尝试多次身份验证无法通过，服务器主动断开了连接，并发送来自远端的错误类型提醒信息。本地也无法在继续进行认证尝试。 

四、使用证书进行登陆——双向，用户/主机证书认证 

      通常情况下，都是使用这种方法。同时对主机和用户认证进行证书化，用户和主机之间借助AC权威建立彼此之间的信任。AC对信任主机通过主机AC签发主机证书，对信任的用户通过用户AC签发用户证书。主机添加对用户AC的信任，用户添加对主机AC的信任。然后主机和用户通过证书进行登陆访问。在这里使用真实主机作为CA，同时生成主机AC密钥host_ac和用户AC密钥user_ac。使用服务器现有的密钥来制作主机证书。用户端使用cnPuTTYgen程序来生成用户的密钥并用来制作用户证书。然后在SSH中使用证书进行登陆。在开始前，对服务器重新生成了SSH主机密钥，所以出现的主机密钥指纹可能跟之前的不一样，只是为了更好的区分设置效果。真实应用当中是不会随意更改主机密钥，同时清除之前单向证书认证中的相关设置，相关过程略。其它过程如下：

(1)、在本地使用Git Bash中的密钥生成程序生成host_ca和user_ca密钥
      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)、从/etc/ssh获取服务器公钥到本地
      在/etc/ssh文件夹中可能存在多个服务器公钥，本次选取ssh_host_ecdsa_key.pub到本地用来制作服务器证书。
(3)、制作服务器证书    
      ssh-keygen -s host_ca -I host.debian -h -n debian,192.168.204.128 -V +52w ssh_host_ecdsa_key.pub
          -s：指定用来签发证书的主机CA密钥
          -I：证书ID字符串
          -h：指定该证书类型是主机证书，而不是用户证书。
          -n debian,192.168.204.128：指定包含在证书中的主体，这里指有效主机。可以是服务器的域名等，也可以是逗号分隔的多个主体。本例中不存在域名解析，所以简单的指定主机名和主机IP作为主体。
          -V +52w：指定证书的有效期为52周
          ssh_host_ecdsa_key.pub：服务器公钥。
          注：更多详细的命令请参考ssh-keygen中与证书有关的命令摘录[转载]~~的相关说明
        完成后会生成一个名为ssh_host_ecdsa_key-cert.pub的文件，与获取的服务器公钥相比多了“-cert”，这个文件就是服务器的证书文件。查看证书信息如下：

//生成的服务器证书信息
$ 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)

​可以看出，证书类型为主机证书，公钥和CA的相关信息，同时也包含了有效期等。
​(4)、为主机添加服务器证书
       将上面生成的服务器证书ssh_host_ecdsa_key-cert.pub，上传到服务器/etc/ssh目录下，并设置对应权限644。
       在SSH配置文件/etc/ssh/sshd_config中添加如下一行信息
       HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub
       重新启动SSH服务
       sudo systemctl restart sshd
       此时服务器已经具备了对外提供证书的能力了。可以进行简单的测试，在服务器或者本地Git Bash中，使用ssh -v来进行简单的测试。比如在服务器上的测试如下

       在Server host certificate字段已经可以看到添加的服务器证书信息了。
(5)、生成用户密钥与公钥信息
       与单向用户证书认证不同的是这里使用cnPuTTYgen来生成用户密码。
            (密钥生成过程略...)
       因为cnPuTTYgen生成的密钥文件与OpenSSH的格式不一样。所以要获取ssh-keygen可用的用户公钥时，可以直接复制生成界面的公钥信息，或者将cnPuTTYgen生成的密钥导出为OpenSSH格式，然后在使用 ssh-keygen -y -f 提取公钥，详细过程略。
       最终获得用户密钥文件jack_user.ppk和公钥文件jack_user。
(6)、制作用户证书，使用用户CA密钥user_ca对用户的公钥文件jack_user公钥进行签名
    ssh-keygen -s user_ca -I jack-cnPuTTY@debain -n jack -V +52w jack_user
        -s：指定用来签发证书的用户CA密钥
        -I：指定证书ID字符串
        -n jack：指定包含在证书中的主体，这里表示证书对谁有效，可以是逗号分隔的多个主体。
        -V +52w：指定证书的有效期为52周
        jack_user：用户公钥        ​
        注：更多详细的命令请参考ssh-keygen中与证书有关的命令摘录[转载]~~的相关说明
       完成后会生成一个名为jack_user-cert.pub的文件，带有“-cert”标志，说明这个文件就是生成的用户证书文件。  查看用户证书信息如下

//用户证书信息
$ 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

       证书的类型为用户证书，同样也包含了相关用户权限的扩展，只是用户CA密钥的算法还有用户密钥的算法跟之前的不同。也可以在本地使用cnPuTTYgen去尝试将密钥和证书进行绑定，过程略。
(7)在服务器端添加对新的用户CA的信任
       服务器已经可以对外提供证书，用户也有自己的证书和密钥文件。但现在还不能进行正常通讯，因为对用户进行证书签发的用户CA，服务器并不知道它的存在。所以需要将用户CA的公钥提交到服务器，并作为可信密钥。
       将用户CA的公钥user_ca.pub上传至服务器/etc/ssh/目录下，设置对应权限644。
       在SSH配置文件/etc/ssh/sshd_config中添加新的用户CA信息
       TrustedUserCAKeys /etc/ssh/user_ca.pub
       重新启动SSH服务
       sudo systemctl restart sshd
(8)在客户端添对主机CA的信任
       服务器可以对外提供证书了，也知晓并信任了新的用户CA。本地也有对应的用户证书和私钥了，是否已经可以正常访问服务器呢？
       这个当然是可以的，参考“使用证书进行登陆——单向，用户证书认证”相关设置。是可以正常访问服务器的。但是如果这样，对于主机的证书安装是完全没有意义的。因为现在登录的话，本地客户端不具备验证主机证书的能力。为了本地能够验证服务器的证书，需要本地设置对主机CA的信任。根据使用客户端的不同可能有差异，这里仅介绍PuTTY/cnPuTTY的相关设置。
       在cnPuTTY主机密钥面板，选择“配置主机CAs”，打开对话框如下

        当前界面是用来添加本地对主机CA的信任。首先在CA的公钥记录中选择读取文件，选择host_ca.pub文件。在下面一行会显示主机CA的指纹信息。然后选择在CA的可信度中，输入有效主机表达式，用来指定在哪些范围使用这个主机CA。本例中在这里选择输入*，表示任何范围。然后指定CA的名称，这个是为了方便用户识别，还有在日志事件中显示。然后点击保存，使相关信息正常记录下来，最后点完成。这里的设置是全局的，对所有会话都有效。
(9)客户端登陆
       现在可以进行客户端登陆了，同样的需要在数据面板指定用户名，在凭证面板指定指定用户私钥和证书文件，然后选择打开。

神奇的一幕发生了，没有任何额外的警告提醒，就直接自动完成登陆了。登陆后如下 

还记得之前特别提醒留意的警告信息吗？？这里似乎什么都没有给用户发出提醒。到底发生了什么？？我们可以查看一下事件日志，记录如下

//双向证书认证登陆的事件日志输出
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

请注意在事件日志中，相关认证信息：服务器以证书的方式给出了主机密钥指纹、包含证书时的指纹信息，还有证书颁发机构的指纹信息。其中证书ID字符串就是我们在签发服务器证书时所指定的内容。后面出现了“host_ca_test”，这个是在本地设置受信任的证书颁发机构时，指定的名称。紧接着提示"接受的证书"。至此完成了通过证书对主机的验证。后续的过程与单向用户证书验证的过程一致。[当前显示信息存需要更正的地方，会在cnPuTTY下一版本修复]

       其实，如果细心的话，应该留意到了在之前使用cnPuTTYgen去尝试合并密钥与证书时，指纹信息的变化。这里为了更清晰的说明相关变化，把制作服务器证书时ssh_host_ecdsa_key.pub对应的密钥拿到本地进行合并操作。将密钥加载到cnPuTTYgen后，提示转换，然后如下

       可以看到来自服务器主机密钥的指纹信息，然后添加证书文件ssh_host_ecdsa_key-cert.pub到密钥，如下

       导入证书后，指纹发生了小变化，以[email protected]开头，但指纹SHA256值与之前的服务器密钥指纹相同。然后查看证书信息如下

       这里包含指纹对服务器公钥进行签发的主机CA的指纹信息，还有一个同时包含证书的指纹信息。现在回过头来查看事件日志、在添加本地信任的证书颁发机构、还有查看生成服务器的证书及对服务器证书是否生效时的验证，相关对应的指纹信息是一致的。当然用户证书相关的验证也是如此。

      除了单独指定密钥和证书文件进行加载使用外，也可以将两者合并，使用身份代理程序进行验证，具体过程略。到这里已经完成了使用证书进行双向认证登陆的操作了，可以正常登陆进行其他操作了。通过事件日志的查看，可以明显的看到各种验证过程的不同。就算使用证书，仅用户侧的单向认证与双向认证也是有差异的。 

       为了了解更多关于双向证书验证的过程，可以做更多的验证。首先在本地尝试使用之前的用户证书或者密钥。在单独更换用户密钥或者证书时，都会有如下提示

 事件日志信息如下

//用户密钥或者证书被替换后
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	远程端意外关闭网络连接

       通过上面的信息[当前显示信息存需要更正的地方，会在cnPuTTY下一版本修复]可以看出，本地对于主机的验证依旧是通过证书方式来完成的，但本地证书和密钥不匹配，最终服务器拒绝了我们，并在规定时间内没有接收到密码输入关闭了与我们的连接。其实在使用cnPuTTYgen进行证书和密钥合并时，只要两者不匹配，就会报错，无法合并。另外通过证书方式访问服务器，本地需要使用用户密钥和用户证书的，不管是使用PuTTY/cnPuTTY还是其他SSH指令连接。本地对密钥和证书的验证都无法通过，服务器当然没有理由接受认可。

       现在尝试改变给服务器签发的证书内容，看看会有什么事情发生。这里只是改变了服务器证书的生成参数，其他设置均未发生变化，详细过程略。客户端没有任何更改，直接登录。会收到如下警告信息

       这里是一个关于CA认证的警告信息[当前界面存需要更正的信息，会在cnPuTTY下一版本修复]，以证书的方式提供了主机密钥指纹，这个跟之前提醒特别留意的警告信息完全不一样。接着查看下事件日志，看看发生了什么

//修改服务器证书的生成参数后的事件日志输出
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

请注意在事件日志中，相关认证信息：[当前界面存需要更正的信息，会在cnPuTTY下一版本修复]对应服务器证书的验证过程与之前一样，不同的是之前提示"接受的证书"，而本次修改后的提示是“被拒绝的主机密钥证书”，理由是当前访问的192.168.204.128不在证书的主机名列表当中。对于本地来说，服务器的证书确实是来自信任的签发机构签发的与证书颁发机构匹配，但当前的服务器是不受这份证书认可的，虽然这个证书已经被安装到服务器上。提示“无论任何时候,都接受经过认证的主机密钥缓存”，接着客户端以证书的方式提供验证信息。

       服务器证书是被本地认可的，但服务器不被证书认可，或者说不属于证书的主体。本地接受并验证了主机证书，发现了问题。在对服务器证书验证信任度的时候同时验证了证书对服务器的适用性。这里使用是命令“ssh-keygen -s host_ca -I host.debian -h -n debian -V +52w ssh_host_ecdsa_key.pub”生成了证书。接着后面的过程与单向的用户证书认证方式一致。那么如果真的改变了服务器证书的签发主机CA，而本地依旧使用旧的主机CA信息会是什么样子？？这里使用Git Bash生成other_ca密钥，并使用“ssh-keygen -s other_ca -I host.debian -h -n debian,192.168.204.128 -V +52w ssh_host_ecdsa_key.pub”对同样的主机公钥ssh_host_ecdsa_key.pub签发证书，然后安装在服务器上使它生效，本地信任旧的host_ca.pub主机CA，详细过程略。新生成的主机证书如下

//新的主机证书
$ 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)

      然后安装到服务器上，并使它成效。在使用本地未修改的客户端进行登陆，没有弹出任何警告信息，事件日志如下

//重新生成主机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

请注意在事件日志中，相关认证信息：[当前界面存需要更正的信息，会在cnPuTTY下一版本修复]以证书形式给出主机的密钥指纹没有改变，因为制作证书时使用的公钥是同一个。但主机AC和包含证书的指纹信息已经改变了，而且直接提示“证书颁发机构不受信任”，之前还只是服务器证书与主机不匹配，现在本地直接不信任证书签发机构了。提示“无论任何时候,都接受经过认证的主机密钥缓存”，接着客户端以证书的方式提供验证信息。

       如果在使用证书进行登陆的设置完成后，主机的密钥发生了变化又会怎么样呢？接下来验证一下，在完成所有正常设置后，重新生成主机密钥。使用cnPuTTY登陆时提示如下

 又出现了普通的主机密钥警告，查看事件日志如下

//证书登陆下，重新生成主机密钥后
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

       可以看出事件日志中没有主机证书的相关信息，之后与证书的单向认证类似。之前主机CA不匹配或者证书的生成方法改变时，事件日志中显示收到一个经过CA认证的证书，并提示“无论任何时候,都接受经过认证的主机密钥缓存” 。当然如果改变服务器用户CA的相关设置，对应用户的验证就又回到之前的密钥或者密码验证了。

       通过更换证书签发方式和更换用于认证的主机CA，都会造成服务器证书认证存在有问题。被第三方认证过的主机密钥，以证书的方式提供给客户端，客户端都会接受。后续的认证过程与单向用户证书登陆的验证一样，因为服务器是认可用户CA的，并且单向用户证书登陆本身是不存在问题的。是否能够提示"接受的证书"这取决于是否进行了正确的服务器证书的签发和安装。如果证书设置不变，服务器主机密钥发生了变化，那么对应主机的验证就又回归原来的密钥验证了。通着这些改变，我们对相关变化对证书验证登陆的影响也有了一个大致的了解。

       其实服务器到现在还没有添加主机CA的相关信息，在本实例中是不影响对证书的验证和使用的。将主机CA的host_ca.pub文件上传至服务器，并添加信息到/.ssh/known_hosts文件当中，然后在行首添加 @cert-authority * 表示当前记录为证书签发机构CA，接着是主机名字段，星号表示匹配所有，也可以指定域名信息，并且可以包含多项内容。这个方法只适用于为当前用户指定主机CA，如果需要全局设置，则需要经过管理员在/etc/ssh/ssh_known_hosts文件中添加信息。添加后测试SSH连接如下：

//服务器安装主机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:  compression: none
debug1: kex: client->server cipher: [email protected] MAC:  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 blocks

       服务器添加了主机CA，并且会信任同一个主机CA认证过的其他主机。在PuTTY/cnPuTTY中添加受信任的证书颁发机构与对known_hosts的修改添加作用类似。如果客户端是使用其他Linux主机或者类似Git Bash/MSYS2这类客户端则需要使用类似的方法对known_hosts添加信息来认可主机CA。证书的支持和使用也可以是全局的或者只设置对某些用户有效，设置过程类似，只是需要修改为文件位置不同而已。

关于证书的吊销

       在使用证书的完整周期中，可以简单的依赖证书的有效期使证书失效，也可以主动吊销证书。通过将公钥添加到revoked_Keys文件并在sshd_config中添加如下信息：

       RevokedKeys /etc/ssh/revoked_keys

请注意，如果此文件不可读，则将拒绝所有用户的公钥身份验证。
要测试是否已被吊销，可查询吊销列表中是否存在对应公钥。按如下方式使用命令：

       ssh keygen-Qf  /etc/ssh/revoked_keys  ~/.ssh/id_rsa.pub

       用户端可以通过在known_hosts文件中将cert-authority证书标记指令更改为revoke指令来吊销CA证书。对于PuTTY/cnPuTTY则直接删除信任的证书签发机构信息来实现撤销对主机CA的信任。

       在描述的所有实例中，其实对于密钥的生成，谁充当了CA，使用哪种密钥算法和生成证书的公钥选取并没有任何严格的限制。确保每一个密钥的安全，特别是使用证书进行验证时CA密钥的安全是非常重要的。

[关于错误信息的说明]
       本文档的目的之一就是“收集一些cnPuTTY的错误信息，用来修改cnPuTTY”。在描述过程已经标注了部分可能存在需要纠正的地方。除了这些外，还收集到的信息有：显示界面修正1处，代理界面信息添加4处，警告提示信息修改10处，网络报错信息3处，一类会话界面打印信息有乱码需要修正，多处事件日志信息显示描述模糊，CA警告信息界面疏漏或者描述模糊等等。这些主要体现在界面显示上，对功能使用没有影响。至少我没有遇到任何功能上的影响。
       目前对于PuTTY的修改主要集中在显示的语言上，目前已经做过，属于cnPuTTY的单独修改是在特定日志模式下，存在中文输出时日志记录内容有乱码。这次收集的相关内容会在下一次进行修正。这里同样提醒：没有人能够确定或者保证cnPuTTY会跟随PuTTY的后续更新发布同步更新，也不能够确保或者保证cnPuTTY自身版本会进行后续更新或者修补，也许cnPuTTY的发布、更新仅仅是一次性的。所以你不需要等待什么，也许PuTTY或者其他可选的方式会是更好的选择。
       更详细的错误信息不是本发布的重点描述，所以此处略过。如果你有使用cnPuTTY的话，当你看到描述的内容有些模棱两可的话，那可能就是了，也许有些你不会遇到。或者是我还没遇到的，如果你愿意告知，我很乐意接受。

[免责声明]在此所有相关内容和有关发布都遵从相同的准则，不提供任何保证、不承担任何责任。也不确保在你的实践中能够完整的重现，你应当充分验证你的需求和设置，以免造成不必要的麻烦。其它相关内容请以对应的许可和说明内容为准。

[参考信息]其他信息可参看如下链接或者对应的原始链接：
        在SSH中使用的公钥证书认证系统 [转载]~~
        ssh-keygen中与证书有关的命令摘录[转载]~~
        ssh-keygen中关于证书部分的相关描述[转载]~~
        Using OpenSSH Certificate Authentication 
        Welcome to the SSH Academy
​        等等其他相关内容。