SSH密钥无法扩展，SSH证书可以

SSH 访问无处不在。它是世界各地的工程师、脚本和平台远程管理 Linux 系统的方式。无论你是在运行一个小型开发服务器，还是在管理一个全球规模的集群，你几乎肯定都会以某种形式依赖 SSH。

传统上，大多数团队会通过创建长效密钥对、将公钥分发到主机，并通过手动分发和清理来管理用户访问，从而使用 SSH 公钥身份验证。虽然这种模式适用于较小规模的部署，但随着需要访问不同机器的人越来越多，它就难以适应复杂的基础设施。最初看似简单的操作，很快就会演变为不断增加的运维和安全风险：密钥管理蔓延、访问边界不清晰，以及难以维护的脆弱工具。

幸运的是，可以通过基于 SSH 证书的身份验证来构建一种更具扩展性的 SSH 方案，而这在 Meta、Uber、Google 等公司已经很常见。希望这篇文章读起来有趣，也能对那些未来可能需要在更大规模上简化 SSH 访问的人有所帮助。

为什么不使用 SSH 公钥身份验证？

不管你是否喜欢，一旦用户和主机的数量不再只是寥寥几个，SSH 公钥身份验证就会变得棘手。最初只是在用户和机器之间生成、安装和跟踪几个 SSH 密钥对，很快就会变成一场具有严重安全后果的运维噩梦。通常情况下，当数十个甚至数百个密钥散落在基础设施中时，组织最终都不得不面对密钥蔓延的问题。

如果没有中心化的密钥管理方法，管理员就很难回答有关可观测性和安全性的问题，例如谁拥有哪些访问权限，以及谁本应拥有哪些访问权限。即使这些问题有了答案，访问管理本身——比如为特定机器授予或撤销用户访问——也会成为另一个麻烦。

我将在下面更详细地说明这些挑战：

• 由于 SSH 公钥身份验证要求用户拥有 SSH 密钥，并且每台主机都需要登记所有被允许访问该主机的用户公钥，因此 SSH 密钥管理就变成了一个运维问题：如何高效且安全地简化用户和主机之间的密钥生成、分发和安装。在最理想的情况下，团队会编写操作手册、脚本，并采用一些脆弱的工具来简化流程；但更多时候，它最终会在用户入职或离开系统时演变成巨大的运维开销。
• 除了密钥管理本身的复杂性之外，密钥蔓延还会带来可观测性方面的问题，尤其是在缺乏中央控制平面的情况下，很难回答哪些用户可以访问哪些主机。结果往往是，访问权限在缺乏适当监督的情况下被过度授予，离职员工和外部承包商仍然保留着残留访问权限，仅仅是因为没人知道要从每台主机上删除他们的密钥。
• 最后，SSH 公钥身份验证还会在安全密钥分发和密钥复用方面助长不良的安全习惯。更具体地说，工程师最终会为了方便，把 SSH 密钥从一个设备复制到另一个设备，通过不安全的渠道传输它们，并在不同环境中重复使用它们。在这种情况下，密钥轮换很少发生，这会扩大密钥丢失或被盗后的影响范围，因为这些密钥在被移除之前会一直保留对主机的永久访问权限。

除了上述这些原因之外，还有许多其他问题。希望现在已经很清楚：从运维和安全的角度来看，基于 SSH 密钥的身份验证并不具备可扩展性，因此需要一种更好的模型，将集中管理、可观测性和安全性结合起来，同时尽量降低实现开销。

于是，基于 SSH 证书的身份验证登场了。

什么是 SSH 证书？

SSH 证书是一种短效、经过加密签名的文档，用于在 SSH 身份验证中证明用户或主机的身份。与 SSH 公钥身份验证不同，后者需要将静态公钥分发到整个基础设施中；而基于 SSH 证书的身份验证引入了一种中心化信任模型，由指定的证书颁发机构（CA）为用户和主机公钥签名，从而生成用于为其身份背书的短效 SSH 证书。

在基于 SSH 证书的身份验证中，你不再需要把单个用户密钥放到每台服务器上，而是将主机配置为信任用户 CA。从那时起，任何持有该 CA 签名的有效证书的用户都可以获得访问权限，但仍需遵守你定义的规则。SSH 证书内置过期时间和身份信息（如主体或角色），并且可以随时撤销或重新签发，因此比长效 SSH 密钥更加灵活和安全。

为什么使用基于 SSH 证书的身份验证？

基于 SSH 证书的身份验证的妙处在于，它可以作为一个基础模块，帮助构建一种我们认为每个人都应该采用的、更理想的 SSH 使用体验。

通过前期投入一些工程工作，可以建立一套由基于 SSH 证书的身份验证驱动的工作流和专用服务，为用户按需颁发可用于访问主机的短效 SSH 证书。这种方法的优势在于，你不再需要管理静态的长效 SSH 密钥，因为它们被按需签发给经服务识别用户的短效 SSH 证书所取代。在这里，访问控制模型从分散式转变为中心化，用户、主机以及它们之间访问权限的授予和撤销，都可以通过专用服务完成，同时你还能对所有用户及其基础设施访问权限拥有完整的可见性。

在我们看来，这才是现代、可扩展的 SSH 访问应有的样子：中心化、可审计，并围绕短效凭据构建。

基于 SSH 证书的身份验证是如何工作的？

实施一套基于 SSH 证书的身份验证方案，确实需要一些前期工程投入、对系统中每个用户和主机进行配置，以及理解其中涉及的底层加密原语和概念。

首先，重要的是要理解，基于 SSH 证书的身份验证依赖 SSH 密钥对（通常是 Ed25519）。其中一些密钥对会被指定为证书颁发机构（CA），用于签署证书；另一些则由用户和主机生成，用于接收证书，并在后续 SSH 连接中使用。不过，不同之处在于，一旦完成系统搭建的前期工作，这些密钥对几乎不再需要管理。

在典型设置中，管理员可以在专用服务中设置两个 CA，其中一个负责签发用户证书，另一个负责签署主机证书。每个用户都会预先配置为信任签发给主机的证书；反过来，每个主机也会被设置为信任签发给用户的证书。这种双向信任构成了基于 SSH 证书的身份验证模型的基础。

配置用户信任

为了确保用户只连接到受信任的主机，每个用户的机器都需要配置为信任主机 CA。这是通过使用特殊的 @cert-authority 标记，将主机 CA 的公钥添加到 known_hosts 文件中来实现的。

例如：

@cert-authority *.example.com ssh-ed25519 AAAAC3Nza...

这行内容会指示用户侧的 SSH 客户端，信任由主机 CA 为 *.example.com 下任意主机签发的主机证书。

配置主机信任

为了确保主机只允许持有有效 SSH 证书的用户访问，并将登录限制在预期的 Unix 帐户上，每台主机都必须进行一些关键配置。

• 为了验证传入的 SSH 证书，必须在每台主机上安装受信任用户 CA 的公钥，并更新 sshd_config 文件，加入 TrustedUserCAKeys 配置指令，例如 TrustedUserCAKeys /path/to/user-ca.pub。
• 为了控制用户能够以什么身份登录，每台主机还必须配置一个或多个 authorized_principal 文件，用来指定传入 SSH 证书中包含的哪些主体（即用户名、角色或组名等身份）可以登录到哪些本地 Unix 用户帐户下（例如 ec2-user、root 等）。

连接工作流

此后，典型的用户 SSH 访问流程如下：

1. 当用户想要访问某台主机时，他们会向包含用户 CA 的专用服务发起授权请求，以获取 SSH 证书。CA 会验证用户身份，并签发一个短效证书，其中包含一个或多个代表用户身份的主体。
2. 证书签发后，它会被加载到用户的 SSH Agent 中。SSH Agent 是一个在内存中安全保存私钥和证书的后台进程。接下来，用户从本地机器发起 SSH 连接，例如 ssh ec2-user@host.example.com。
3. 在主机上，SSH 守护进程会验证用户证书是否由受信任的用户 CA 签名。然后，它会查找与登录用户关联的 authorized_principals 文件，以检查用户证书中列出的主体是否有权限登录该帐户。
4. 回到用户的机器上，SSH 客户端会通过对照存储在用户 known_hosts 文件中的受信任主机 CA，检查主机的 SSH 证书，从而验证主机身份。

走进 Infisical SSH

Infisical SSH 为你的团队和基础设施提供了一个安全、可扩展的控制平面，用于启用基于 SSH 证书的访问。

我们努力抽象掉了搭建基于 SSH 证书访问所需的全部运维复杂性，从运行 CA 到签发证书和配置信任。我们极大地简化了整个设置流程，因此你唯一需要关心的，就是将用户和主机注册到平台上，并指定谁应该访问什么。

整个工作流通常包括三个步骤：

1. 使用 Infisical CLI，通过 infisical ssh add-host 命令在 Infisical 中注册主机。
2. 配置 Infisical，通过其基于角色的访问控制框架授予用户对主机的限时访问权限。
3. 用户在自己的机器上使用 Infisical CLI 运行 infisical ssh connect 命令，并选择他们想连接的主机。

在底层，Infisical 会帮助建立双 CA 方案、在主机和用户侧执行所需的信任配置，并签发 SSH 证书并将其加载到 SSH Agent 中，以便在 SSH 连接中使用。

这是 SSH 的未来吗？

SSH 证书在 Meta、Uber 和 Google 等公司已经是标准做法——更多团队采用这种模式只是时间问题。如果你是为了规模、安全或理智而构建，那么在 SSH 访问变得难以管理之前，现在就值得认真考虑切换。

无论你是自己实现，还是使用像 Infisical SSH 这样的解决方案，有一点已经很明确：SSH 密钥无法扩展，SSH 证书可以。

• 原文链接： infisical.com/blog/ssh-k...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～