如果你维护 3 台以内 Linux 服务器，把管理员的 SSH（安全外壳远程登录协议）公钥逐台写入 ~/.ssh/authorized_keys 通常还能接受；但当服务器数量增长到 10 台、30 台甚至更多，人员入职、离职、临时授权和密钥轮换就会变成重复且容易出错的工作。本文是一份 SSH 证书认证实战指南，重点解决“长期公钥散落在多台服务器上不好管理”的问题，帮助你用短期证书替代大规模手工分发公钥。
SSH 证书认证的核心思路并不复杂：服务器不再信任每一个用户公钥，而是信任一个受控的 CA（证书签发机构）公钥；用户每次登录时携带自己的公钥和一张由 CA 签发的短期证书。证书可以写明用户名、可登录账号、有效期和序列号，过期后自动失效，不需要你再到每台服务器上删除同一把公钥。
这篇文章会按照“适用场景→CA 规划→服务端配置→客户端签发→回收与审计”的顺序展开。示例命令基于 OpenSSH 常见用法，适合中小团队、外贸站点运维、开发测试环境和多台 VPS（虚拟专用服务器）或独立服务器（独享物理服务器）场景参考。
为什么长期公钥管理会失控
传统 SSH（安全外壳远程登录协议）公钥认证依赖 authorized_keys 文件。每新增一个管理员，你需要把他的公钥追加到每台目标服务器；每撤销一个人，又要确认所有服务器都删除了对应公钥。单台服务器问题不大，真正的风险来自规模和时间。
举个常见例子：一个团队有 8 名研发和运维成员，维护 20 台 Linux 服务器。如果每个人都有 1 把登录公钥，理论上就有 160 个“用户公钥与服务器”的关系需要保持正确。只要其中 1 台服务器漏删离职人员的公钥，这个授权就会继续存在，而且不一定会被日常巡检发现。
更麻烦的是临时授权。比如你只希望某位工程师在 2 小时内排查线上日志，传统做法往往是“先加公钥，排查完再删”。如果第二步被遗漏，临时权限就变成长期权限。SSH 证书认证把这个问题前移到签发阶段：证书签发时就写入有效期，例如 +2h，到期后即使服务器上没有任何删除动作，登录也会被拒绝。
从运维角度看，SSH 证书认证不是替代所有安全措施，而是把“信任谁”从每台服务器的静态文件收束到可审计的签发流程。规划服务器登录基线时，可以参考国外服务器的数据与业务安全加固思路，把证书认证纳入整体访问控制一起设计。
先设计 CA：不要把签发钥匙放在普通跳板机上
在 SSH 证书认证中，CA 私钥是整套机制的核心。如果 CA 私钥泄露，攻击者就可能签发看似合法的登录证书。因此第一步不是写配置，而是确定 CA 密钥如何生成、存放和使用。
建议至少区分两类 CA：用户证书 CA 和主机证书 CA。用户证书 CA 用来给管理员、开发者或自动化任务签发登录证书；主机证书 CA 用来证明服务器身份，减少首次连接时人工确认指纹的风险。本文重点讲用户证书认证，主机证书可以在后续稳定后再逐步接入。
生成用户 CA 密钥可以使用下面的命令：
mkdir -p /root/ssh-ca
chmod 700 /root/ssh-ca
ssh-keygen -t ed25519 -f /root/ssh-ca/user_ca -C "user-ca-2026"
这里使用 ed25519 是因为它在现代 OpenSSH 环境中广泛支持，密钥短、性能好，也便于人工核对指纹。生成后，user_ca 是私钥，必须限制访问；user_ca.pub 是公钥，可以分发到受管服务器。
服务端配置：让服务器信任 CA 公钥
准备好 CA 后，需要把 CA 公钥部署到每台 Linux 服务器，并修改 SSH（安全外壳远程登录协议）服务端配置。这个过程只做一次，后续新增用户不再需要逐台追加个人公钥。
先把 user_ca.pub 放到服务器固定路径，例如：
sudo install -m 0644 user_ca.pub /etc/ssh/user_ca.pub
然后在 /etc/ssh/sshd_config 中加入或确认下面的配置：
TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile .ssh/authorized_principals
TrustedUserCAKeys 表示这台服务器信任哪个用户 CA 公钥；AuthorizedPrincipalsFile 用来限制证书里的 principal（可理解为证书声明的登录身份）能映射到哪些本地账号。为了避免“任何被 CA 签过的证书都能登录所有账号”，建议为关键账号配置 authorized_principals。
例如你希望某个证书只能登录 deploy 账号，可以在目标服务器上创建：
sudo mkdir -p /home/deploy/.ssh
sudo sh -c 'echo deploy-prod > /home/deploy/.ssh/authorized_principals'
sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_principals
修改配置后先做语法检查，再重载服务：
sudo sshd -t
sudo systemctl reload sshd
如果你的系统服务名是 ssh 而不是 sshd，可以执行 systemctl status ssh 确认。
客户端签发：用短期证书替代长期公钥
服务端信任 CA 后，用户仍然保留自己的本地 SSH（安全外壳远程登录协议）密钥，例如 ~/.ssh/id_ed25519.pub。区别在于，这把公钥不再直接写入所有服务器，而是交给 CA 签发一张短期证书。
一个典型签发命令如下：
ssh-keygen -s /root/ssh-ca/user_ca -I johnson-prod-20260815-001 -n deploy-prod -V +4h -z 1001 /home/johnson/.ssh/id_ed25519.pub
几个参数需要认真理解：-I 是证书身份说明，建议包含申请人、环境和日期；-n 是 principal，必须与服务端 authorized_principals 中允许的值匹配；-V +4h 表示证书从现在起 4 小时内有效；-z 1001 是序列号，便于后续审计或撤销。命令执行后会生成 id_ed25519-cert.pub，用户登录时 OpenSSH 通常会自动匹配同名证书。
登录命令仍然很熟悉：
ssh -i ~/.ssh/id_ed25519 deploy@203.0.113.10
如果要显式指定证书，可以这样写：
ssh -i ~/.ssh/id_ed25519 -o CertificateFile=~/.ssh/id_ed25519-cert.pub deploy@203.0.113.10
这里的关键收益是“权限天然有截止时间”。例如线上排障签发 2 小时，灰度发布签发 4 小时，日常值班签发 8 小时。到了有效期，证书自动失效，服务器无需感知工单是否关闭。相比把同一把长期公钥分发到 20 台服务器，这种方式更适合权限频繁变化的团队。
回收与限制：不要只依赖过期时间
短期有效期可以减少忘记回收的风险，但不能覆盖所有情况。比如证书刚签发 4 小时，用户设备在 10 分钟后丢失；或者某个账号被误签了过大的 principal。此时你需要配合撤销列表和服务端限制。
OpenSSH 支持通过 RevokedKeys 配置撤销证书或公钥。你可以把需要禁用的证书 key ID、序列号或公钥加入撤销文件，再在 sshd_config 中配置：
RevokedKeys /etc/ssh/revoked_keys
更新撤销文件后同样先执行 sshd -t，再重载 SSH（安全外壳远程登录协议）服务。撤销列表适合处理“还没过期但必须立即停用”的证书。为了让撤销有效，签发时必须坚持使用唯一序列号和可读的 key ID，否则事后很难确认该撤销哪一张证书。
对外贸站点或业务网站来说，登录安全只是整体稳定性的一部分。你还需要配合备份、监控和访问控制一起做，相关基础设施选择可以参考 Hostease 的VPS（虚拟专用服务器）方案、独立服务器（独享物理服务器）方案，以及WordPress 相关运维内容，根据访问量、权限隔离和运维能力决定承载方式。
落地前的检查清单
SSH 证书认证最怕“一次性全量切换”。更稳妥的方式是先选 2 台非核心服务器做试点，确认签发、登录、审计和回滚流程都顺畅，再逐步覆盖生产服务器。下面这组检查可以作为上线前的最小标准：
- CA 私钥只保存在 1 个受控位置，并设置
chmod 600或更严格的访问控制。 - 每张用户证书有效期有明确上限，生产临时授权建议从
+2h或+4h开始。 authorized_principals已按账号拆分，避免一张证书登录所有本地用户。- 签发日志至少记录申请人、principal、序列号、有效期和审批来源。
- 试点服务器已验证
sshd -t、新会话登录、过期证书拒绝和撤销列表生效。
执行验证时，不要只测试“能不能登录”，还要测试“该拒绝时是否拒绝”。例如签发一个 -V -1h:+1h 的短证书确认正常登录，再签发一个不匹配 principal 的证书确认失败。你也可以在测试环境里把证书有效期设为 +2m，等待 2 分钟后再次登录，观察服务器是否拒绝过期证书。
总结：把登录权限从“长期散落”改成“短期可审计”
SSH 证书认证的价值，不在于命令本身多复杂，而在于它改变了权限管理模型。长期公钥适合小规模、低变化环境；当服务器和人员数量上来后，短期证书能让授权有有效期、有 principal 边界、有序列号记录，也更容易配合撤销和审计。
如果你需要管理多台 Linux 服务器，建议从 2 台低风险服务器开始试点：生成用户 CA、配置 TrustedUserCAKeys、为一个普通账号写入 authorized_principals、签发 2 小时证书并验证过期拒绝。确认流程稳定后，再把签发审批、日志留存和撤销列表纳入日常运维。这样做的好处是，即使暂时不引入复杂平台，也能先把最容易遗漏的长期公钥问题收束起来。