OpenSSH 用户证书教程：CA 签发、有效期与撤销
用 OpenSSH 原生 CA 为 VPS 管理员签发短期用户证书，配置 TrustedUserCAKeys、principal、序列号和 KRL，并通过双会话验证与安全回滚上线。
OpenSSH 用户证书教程：CA 签发、有效期与撤销
当 VPS 数量增加时，逐台维护 authorized_keys 很容易留下离职账号、过期设备和无法解释的公钥。OpenSSH 用户证书让服务器只信任一个或少量 CA 公钥，管理员的普通 SSH 公钥经过 CA 签名后，携带身份、principal、有效期与限制选项。它不是 HTTPS 使用的 X.509 证书，也不需要浏览器或公网证书机构。
本文采用离线 CA、短期用户证书和逐台灰度配置。开始前先保留现有密钥入口，并按nftables 防火墙教程确认管理端口；sshd 的进程管理与日志排查可以结合systemd 服务教程执行。
建立离线 CA 与信任文件
在不直接暴露于公网的管理环境生成专用 CA：ssh-keygen -t ed25519 -f user_ca -C user-ca。CA 私钥应加密保存，并限制访问；服务器只需要 user_ca.pub。不要把 CA 私钥复制到每台 VPS，也不要用同一把 CA 同时承担用户证书和主机证书用途。
把公钥放到服务器受 root 管理的位置，例如 /etc/ssh/user_ca.pub，权限保持只读。在 sshd_config 中设置 TrustedUserCAKeys /etc/ssh/user_ca.pub。该指令告诉 sshd 信任哪些 CA 来验证用户证书，但证书中的 principal 仍需与登录账户或显式授权规则匹配。
修改配置前运行 sshd -t 做语法检查，保持当前 SSH 会话不退出，再平滑重载服务。不要立刻删除原有 authorized_keys；先用第二个终端完成证书登录、失败路径和回滚验证。
签发带身份与有效期的用户证书
管理员在自己的设备生成普通密钥，把公钥提交给签发流程。CA 端可执行 ssh-keygen -s user_ca -I ticket-1234 -n deploy -V -5m:+8h -z 1001 admin.pub。其中 -I 是会写入日志的 key ID，适合关联工单或人员；-n 指定 principal；-V 设置有效期；-z 写入可跟踪的序列号。
起始时间略微提前可以容忍小幅时钟偏差，但不能替代 NTP。有效期应与任务持续时间匹配，避免使用永久证书。签发后会产生 admin-cert.pub，客户端在私钥旁保留该证书，或者通过 SSH 配置明确指定 CertificateFile。用 ssh-keygen -L -f admin-cert.pub 检查证书类型、CA 指纹、key ID、principal、有效期和扩展项。
principal 不应随意写成所有服务器的 root。可以按角色设计 deploy、ops-readonly 等名称，并在服务器端通过 AuthorizedPrincipalsFile 为本地账户列出允许的 principal。这样，同一证书只有在目标账户明确接受其角色时才生效。
限制能力并验证登录
签发证书时可以用 -O 控制 agent forwarding、端口转发、PTY 等扩展或限制。默认行为应先在官方手册中核对，再按实际任务最小化能力。自动化发布账号通常不需要交互式 shell；运维人员也未必需要远程转发。限制必须在测试环境验证，避免脚本依赖被意外切断。
客户端使用 ssh -vv 可查看是否提交了证书，服务器用认证日志核对 key ID 与 principal。应至少测试正确账户成功、错误 principal 失败、过期证书失败、未受信 CA 失败，以及原有应急入口仍可用。只有新路径稳定后，才逐步清理分散的长期公钥。
撤销、轮换与审计
短有效期降低长期泄露风险，但紧急事件仍需撤销。ssh-keygen -k 可以创建 Key Revocation List，按证书、公钥、序列号或 key ID 管理撤销项；服务器通过 RevokedKeys 指向 KRL 文件。更新 KRL 后先验证文件可读和配置语法，再重载 sshd，并测试目标证书被拒绝。
CA 轮换时，可在 TrustedUserCAKeys 文件中暂时并列旧、新 CA 公钥，先让签发系统切换，再等待旧证书自然过期，最后移除旧 CA。若 CA 私钥疑似泄露，应立即停止签发、部署撤销策略并更换信任根，而不是只删除某个管理员公钥。
审计记录至少保留申请人、审批、key ID、序列号、principal、有效期、CA 指纹和撤销原因。CA 私钥最好置于离线介质、硬件令牌或受控签名服务，日常服务器不应能读取它。
安全上线顺序
先在一台非关键 VPS 建立 CA 信任与 principal 映射，签发数小时有效的测试证书，执行正反向用例；随后再灰度到生产。任何时候都保留独立的应急访问方式，并在变更结束后确认应急凭据受到额外保护。
OpenSSH 证书真正解决的是集中信任和短期授权，而不是把一把长期私钥换成另一把长期私钥。只有把签发、有效期、principal、撤销、日志与 CA 保管连成闭环，证书体系才比散落的 authorized_keys 更容易控制。
