如果您不使用 SSH 证书，那么您使用 SSH 的方式就错了 | 第 2 集：证书可提高可用性、可操作性和安全性

在上一篇文章中，我们讨论了使用证书而非密钥进行 SSH 连接的优势。在本期文章中，我们想重点介绍如何通过证书迁移来改善开发人员、运维人员和安全团队的工作效率。

证书认证提高了可用性

使用公钥认证，当您第一次通过 SSH 连接到远程主机时，您将看到如下安全警告：

$ ssh ubuntu@ec2-54-161-77-102.compute-1.amazonaws.com
The authenticity of host 'ec2-54-161-77-102.compute-1.amazonaws.com (54.161.77.102)' can't be established.
ECDSA key fingerprint is SHA256:2ae53QcOB0W6HO+XtPmMXk7To/MvMuhFxTj8ZD7eSsE.
Are you sure you want to continue connecting (yes/no)?

你可能以前见过这种情况。如果你和大多数人一样，已经习惯了直接输入“yes”就忽略它。这很麻烦，因为这是一个真正的安全威胁。而且，它的用户体验也相当糟糕。我敢打赌，绝大多数 SSH 用户实际上并不理解这个警告。

当您通过 SSH 连接到主机时，该主机会对您进行身份验证。您的 SSH 客户端也会尝试对主机进行身份验证。为此，您的客户端需要知道主机的公钥。主机公钥存储在 中的一个简单的数据库中~/.ssh/known_hosts。如果您的客户端在此数据库中找不到主机的公钥，您会收到此警告。它告诉您主机无法通过身份验证！

你应该做的是通过询问管理员或查阅数据库之类的方式，在带外验证密钥指纹。但没有人会这样做。当你输入“是”时，连接无需身份验证即可继续，并且公钥将永久添加到~/.ssh/known_hosts。这就是“首次使用信任”（TOFU）反模式。

由于证书身份验证使用证书来传递公钥绑定，因此客户端始终能够进行身份验证，即使是首次连接到主机。TOFU警告消失。

证书身份验证还提供了一个便捷的时机，可以通过自定义身份验证来控制 SSH：证书颁发时。这可以用来进一步增强 SSH 的可用性。具体来说，它允许您将单点登录 (SSO) 扩展到 SSH。SSH 的 SSO 是证书身份验证最大的亮点。稍后我们将回顾这个想法，并看看它如何进一步增强可用性和安全性。现在，让我们先讨论可操作性。

证书认证提高可操作性

消除密钥审批和分发可带来立竿见影的运营效益。您无需再将运维周期浪费在繁琐的密钥管理任务上，还能省去监控和维护自建设备（用于在整个集群中添加、删除、同步和审核静态公钥文件）相关的任何持续成本。

通过多种身份验证机制颁发 SSH 用户证书的能力也有助于实现操作自动化。如果某个 cron 作业或脚本需要 SSH 访问，它可以在需要时自动获取临时 SSH 证书，而无需预先配置长期有效的静态私钥。

SSH 公钥身份验证引入了一些围绕主机名的奇怪操作限制，而证书身份验证则消除了这些限制。正如我们所见，当 SSH 客户端首次连接到主机时，它会向用户显示一个 TOFU 警告。当用户输入“yes”时，主机的公钥将被本地添加到~/.ssh/known_hosts。主机名和特定公钥之间的这种绑定是永久的。如果主机稍后提供不同的公钥，用户将收到一条更可怕的主机密钥验证失败错误消息，如下所示：

$ ssh ubuntu@ec2-54-161-77-102.compute-1.amazonaws.com
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:2ae53QcOB0W6HO+XtPmMXk7To/MvMuhFxTj8ZD7eSsE.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in ~/.ssh/known_hosts:11
ECDSA host key for ec2-54-161-77-102.compute-1.amazonaws.com has changed and you have requested strict checking.
Host key verification failed.

这使得重用主机名在操作上变得非常困难。如果prod01.example.com发生硬件故障，并将其替换为使用相同名称的新主机，则会导致主机密钥验证失败。这通常会导致一群工程师联系安全警卫，告知他们遭到了黑客攻击。

忽略主机密钥验证失败的攻击面与完全不知道密钥的情况完全相同。奇怪的是，当密钥未知（TOFU）时，OpenSSH 会选择软失败，并给出一个容易绕过的提示；而当密钥不匹配时，OpenSSH 则会选择硬失败，并给出一个更可怕、更难以绕过的错误提示。

无论如何，证书可以解决所有这些问题，因为在建立连接时会传递当前的名称到公钥的绑定。更改主机的公钥是可以的，只要主机也获得新的证书即可。您可以安全地重用主机名，甚至可以使用相同的名称运行多个主机。您将再也不会看到主机密钥验证失败的情况。除了名称重用之外，我们很快就会发现，消除主机密钥验证失败是证书身份验证促进良好安全卫生的众多方法之一。

证书认证提高了安全性

虽然 SSH 协议本身是安全的，但公钥认证会鼓励一系列不良的安全实践，并使良好的安全卫生难以实现。

使用公钥认证，密钥将永久受信任。私钥泄露或非法密钥绑定可能会长期不被察觉或报告。密钥管理疏忽（例如，忘记从主机中删除前员工的公钥）会导致 SSH 无法打开：未经授权的访问将永无止境。

另一方面，证书会过期。一旦发生事故——无论是错误、盗窃、滥用还是任何形式的密钥泄露——即使事故未被发现或报告，被盗用的 SSH 凭证也会自动过期，无需干预。SSH证书具有故障安全保护功能。如果不采取措施延长证书有效期，访问权限将自然过期。当 SSH 用户和主机定期向 CA 签入以更新其凭证时，会生成完整的审计记录。

我们已经看到公钥认证如何训练用户忽略严重的安全警告（TOFU）并触发虚假的安全错误。这不仅仅是操作上的麻烦。主机密钥验证失败造成的混乱会阻碍主机密钥更新（即替换主机的密钥对）。主机私钥的保护措施并不完善，因此定期进行密钥更新是一种良好做法。在发生泄露或用户下线后，可能需要进行密钥更新。但是，为了避免随后的主机密钥验证失败造成的中断，通常不会这样做。证书认证使主机密钥更新变得轻而易举。

公钥认证也给用户带来了密钥更新的困难。密钥的批准和分发本身就很烦人，即使你开发了相应的工具，用户也不愿意进行密钥更新。更糟糕的是，用户会复制私钥，并在不同设备之间重复使用，这种情况通常会持续很多年。密钥重复使用是严重的安全隐患。私钥不应该通过网络传输。但 SSH 公钥认证会直接暴露给用户敏感的私钥，却无法为他们提供可用的密钥管理工具。这很容易导致密钥滥用。

SSH CA 搭配一个简洁的命令行客户端，可以简化密钥生成流程，并使用户免于处理大量不必要的细节。证书身份验证并不能完全消除所有安全风险，但它确实简化了 SSH 工作流程，使其更加直观、易于使用且更难被滥用。

要了解有关 SSH 证书的更多信息，请访问Smallstep 网站。您甚至可以试用我们的免费托管服务，并在五分钟内体验 SSH 证书的价值！