SSH 证书认证权限治理封面图

SSH 证书认证权限治理：降低多台 Linux 服务器账号风险

作者

SSH 证书认证权限治理封面

很多团队一开始只管理 1 台 Linux 服务器，后来扩展到 5 台、20 台甚至更多，authorized_keys 里的长期公钥就会逐渐失控：离职人员有没有删干净、外包临时权限什么时候过期、哪把密钥对应哪次变更，都很难回答。本文教你如何用 SSH 证书认证把“长期放行”改成“短期授权”，帮助运维团队降低多台 Linux 服务器的账号风险。

这一篇不重复讲“如何生成一把 SSH key”，而是聚焦权限治理场景：谁来签发、证书多久过期、服务器信任什么、如何验证和撤销。读完后，你可以先在 2 台测试机上完成最小闭环，再决定是否推广到生产环境。

长期公钥为什么会变成权限债务

传统 SSH 公钥登录的思路很直接：把用户公钥写进目标账号的 ~/.ssh/authorized_keys，只要私钥还在，登录就一直有效。单机环境下这很方便；但当你同时维护多台 服务器，每个人又需要访问不同环境时，公钥就会变成分散在各台机器上的长期授权记录。

常见问题通常不是“SSH（安全外壳协议）不安全”，而是授权生命周期没有被管理。比如一名外包工程师只参与 7 天排障，公钥却留在 12 台服务器上；一位运维同事转岗后，测试机上的旧公钥无人清理；某个 root 账号下累计了 30 行公钥，但没有人知道其中 8 行是否还在使用。

SSH 证书认证的价值在这里：服务器不再逐个信任每个人的长期公钥，而是信任一个受控的用户 CA（证书签发密钥）。用户拿自己的公钥向 CA 申请短期证书，证书里写明登录身份、有效期、序列号和 principal（可登录主体）。到期后证书自动失效，即使某台服务器没有及时清理用户原始公钥，也不会继续放行这张证书。

长期公钥分散风险示意

先设计边界：CA、账号和有效期怎么定

在动手配置前，建议先把权限边界写清楚。SSH 证书认证不是把所有人都放进一个“大门”，而是把不同角色的访问拆成可审计的短期授权。小团队可以先从一个用户 CA 开始；如果生产、测试、外包访问差异很大，也可以拆成多套 CA，但第一轮不要过度复杂化。

一个可落地的基线可以这样定：

  • CA 私钥只保存在 1 台签发机或受控密钥管理环境中，权限设置为 600，不放到业务服务器。
  • 普通运维证书有效期设置为 8 小时，外包或临时排障证书设置为 2 小时，避免跨天遗留。
  • principal 只写允许登录的系统账号，例如 deploy、ops，不要直接把所有证书都签成 root。
  • 每次签发记录至少保存证书 ID、序列号、申请人、目标环境、有效期和审批单号 6 个字段。

这里的重点是“短期”和“可追溯”。如果证书有效期仍然设置成 90 天，或者签发记录只存在聊天记录里，治理效果会明显下降。对运行在 VPS（虚拟专用服务器）、独立服务器（专用物理服务器）或混合环境中的业务来说，先把登录入口收束到同一套签发流程，比一次性改完所有账号更现实。Hostease 用户在规划多台服务器登录边界时，也可以把这类短期授权策略纳入日常运维规范。

SSH 证书信任边界示意

配置服务器信任用户 CA

确认边界后，可以先在一台非生产服务器上验证。下面示例使用 OpenSSH 常见配置，命令路径可能因系统发行版略有差异，执行前请先确认 sshd -T 能正常输出配置。

先在签发机生成用户 CA。这个 CA 用来签发“用户登录证书”，不要和服务器主机证书混用：

sudo install -d -m 700 /opt/ssh-ca/user-ca
ssh-keygen -t ed25519 -f /opt/ssh-ca/user-ca/ca_user -C "user-ca-20260806"
sudo chmod 600 /opt/ssh-ca/user-ca/ca_user

然后把 CA 公钥复制到测试服务器，例如放到 /etc/ssh/ca_user.pub，并在 sshd_config 中声明信任它：

sudo install -m 644 ca_user.pub /etc/ssh/ca_user.pub
echo "TrustedUserCAKeys /etc/ssh/ca_user.pub" | sudo tee -a /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl reload sshd

TrustedUserCAKeys 的含义很简单：只要用户提交的 SSH 证书由这个 CA 签发，并且 principal 与目标账号匹配，服务器就允许继续走认证流程。它不会让任意证书都能登录，也不会替代系统账号、sudo 权限和防火墙策略。你仍然需要配合最小权限账号、操作审计和必要的登录来源限制。

如果你正在做 网站性能与基础设施优化，也可以把这一步纳入变更窗口：先在低峰期 reload SSH 服务，保留一个已登录的维护会话，确认新会话能登录后再退出旧会话，避免误配置把自己锁在服务器外。

签发短期证书并验证登录

服务器信任 CA 后，用户仍然使用自己的本地密钥对。假设用户公钥为 alice_ed25519.pub，只允许她在当天排障窗口内登录 deploy 账号，可以这样签发 4 小时证书：

ssh-keygen -s /opt/ssh-ca/user-ca/ca_user \
  -I "alice-prod-fix-20260806" \
  -n deploy \
  -V +4h \
  -z 2026080601 \
  alice_ed25519.pub

命令执行后会生成 alice_ed25519-cert.pub。其中 -I 是证书标识，建议写到工单或变更记录里；-n deploy 表示该证书只能作为 deploy principal 使用；-V +4h 表示从当前时间起 4 小时内有效；-z 是序列号，后续撤销和审计会用到。

用户登录时可以显式指定私钥和证书：

ssh -i ~/.ssh/alice_ed25519 \
  -o CertificateFile=~/.ssh/alice_ed25519-cert.pub \
  deploy@example-server

如果登录失败，不要马上回退到长期公钥。更稳的排查顺序是：先用 ssh-keygen -L -f alice_ed25519-cert.pub 检查证书有效期和 principals；再检查服务器 /etc/ssh/ca_user.pub 是否与签发 CA 公钥一致；随后查看认证日志中是否出现 Certificate invalid、name is not a listed principal 或 CA key not found；最后确认目标系统账号是否存在。

这一步验证通过后，才说明“短期授权”链路真的成立。你可以把同一套配置复制到第二台测试服务器，验证同一张证书是否能按预期访问允许的账号，同时无法访问未授权账号。对于多台 独立服务器（专用物理服务器），建议先选 2 台低风险机器试点，观察 1 周再推广。

短期证书签发和登录验证示意

撤销、轮换和日常维护怎么落地

证书认证真正好用的地方，不只是“能签”，而是“能管住”。如果一名员工离职，或者某次临时授权结束，你应该能很快让旧证书失效，而不是挨个去删每台服务器上的公钥。常见做法是维护撤销列表，并把它同步到所有接收证书的服务器。

可以把日常维护拆成 3 个动作：

  • 新增访问前，先确认申请人、工单和目标账号；证书有效期尽量按小时而不是按天设置。
  • 人员离岗或项目结束时，先撤销证书，再检查是否还有长期公钥残留。
  • CA 轮换前，预先在测试服务器验证新旧 CA 的并行信任，避免一次切换导致大面积登录失败。

如果你已经在用 WordPress主机 或其他标准化托管环境，也可以把这些动作纳入统一变更清单。这样做的好处不是“看起来更高级”，而是当服务器数量增加时，你仍然知道谁能进、为什么能进、什么时候该退出。

什么时候适合从公钥迁到证书认证

不是所有场景都必须立刻上 SSH 证书认证。如果你只有 1 台测试机、3 个固定账号，而且人员变动很少，长期公钥未必立刻成为瓶颈。证书认证更适合下面几种情况：

  • 服务器数量已经明显增多，单台手工维护 authorized_keys 开始费时。
  • 临时人员、外包或跨团队访问较多，需要更明确的过期边界。
  • 安全审计要求你能说明“谁在什么时间以什么身份访问了服务器”。
  • 你希望把登录权限从“手工清单”升级成“统一签发+自动过期”。

如果你的团队正处在这个阶段，先从一组非核心服务器试点会更稳。不要一上来就把所有业务机器切换到证书认证；先完成 CA、签发、验证、撤销这条最小闭环，再把经验复制到更大的环境。

总结

SSH 证书认证的核心不是替代 SSH 公钥，而是把“长期授权”变成“短期、可追溯、可撤销的授权”。对于多台 Linux 服务器来说，这种变化会直接减少公钥残留、离职账号遗留和临时权限失控的问题。你可以先在测试环境跑通 CA 信任、短期签发和撤销流程，再把它扩展到生产。

如果你正在做权限治理，建议下一步先选 2 台非生产服务器，按本文的方式完成一次完整演练：签发 4 小时证书、验证登录、到期后复测失效、最后检查撤销和轮换记录。只要这条链路跑顺，后续再扩展到更多服务器就会轻松很多。

发表评论