SSH CA自动化信任管理的核心是统一信任签名密钥，通过离线生成CA密钥对、分发公钥、分别签发用户/主机证书、服务端与客户端配置验证策略，实现零手动操作的动态信任闭环。
用 SSH CA 实现自动化信任管理，核心是让所有 SSH 服务器和客户端统一信任同一个签名密钥（CA 私钥），不再手动分发公钥或维护 known_hosts。关键不在于“生成一堆证书”，而在于建立可信签名链、规范证书生命周期，并让 OpenSSH 自动验证——配置对了，新增机器或用户几乎零手动操作。
生成并安全保管 SSH CA 密钥对
CA 的私钥是整个信任体系的根，必须离线生成、严格权限控制、禁止上传到任何服务器。
- 在可信离线环境执行：
ssh-keygen -t ed25519 -f ssh_ca -C "ssh-ca@company"，生成ssh_ca（私钥）和ssh_ca.pub（公钥） - 私钥权限设为
600，且只保留在 CI/CD 或运维管理员本地；公钥ssh_ca.pub是唯一需分发的文件 - 建议用密码加密私钥（
-N "your-passphrase"），签名时需输入，防未授权使用
为用户和主机分别签发证书
OpenSSH 要求用户证书和主机证书使用不同标识（-I）和用途（-V、-h），不能混用。
-
签发用户证书：用用户公钥 + CA 私钥签名，指定有效期和可登录用户名
ssh-keygen -s ssh_ca -I "alice@dev" -n "alice" -V +52w id_alice.pub
其中-n "alice"表示该证书只允许以用户名alice登录，-V +52w表示有效期 52 周 -
签发主机证书：用主机公钥签名，必须加
-h标志表明是 host cert，并指定主机名（支持通配符）ssh-keygen -s ssh_ca -I "web-prod" -h -n "*.prod.example.com" -V +26w ssh_host_ed25519_key.pub
签完后将生成的ssh_host_ed25519_key-cert.pub和原私钥一起部署到目标主机
服务端与客户端统一启用证书验证
仅签发证书不够，OpenSSH 必须明确知道该信任谁、验证什么。配置分散在服务端（sshd）和客户端（ssh_config / user config）。
-
服务端（/etc/ssh/sshd_config）：
TrustedUserCAKeys /etc/ssh/ca_users.pub← 指向 CA 公钥（用户证书验证）HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub← 主机证书路径HostKey /etc/ssh/ssh_host_ed25519_key← 对应私钥（必须存在）
重启 sshd：systemctl restart sshd -
客户端（~/.ssh/config 或 /etc/ssh/ssh_config）：
Host *.prod.example.comUserKnownHostsFile /dev/nullStrictHostKeyChecking yesVerifyHostKeyDNS yes← 启用 DNS SSHFP 记录可选，但非必需
更推荐显式信任 CA：Host *.prod.example.comUserKnownHostsFile /dev/nullStrictHostKeyChecking yesGlobalKnownHostsFile /etc/ssh/ca_hosts.pub← 写入 CA 公钥（主机证书验证）
集成到自动化流程（Ansible / CI）
手工签发不可持续。把证书签发变成流水线一步，实现“提交配置 → 自动部署 → 自动信任”闭环。
- Ansible 示例：用
community.crypto.openssh_certificate模块签发，私钥不落盘，通过 Vault 注入；证书直接写入目标节点 - CI 流水线中，用户证书由 IAM 系统触发（如 GitLab MR 合并后调用签名 API），主机证书随 Terraform 创建实例自动签发并注入 userdata
- 定期轮换 CA 密钥？用新 CA 签发过渡期双证书，旧证书保持有效直到过期，避免中断
不复杂但容易忽略：证书的 -n 字段必须精确匹配登录用户名或主机名，大小写和通配符规则要一致；客户端若没配置 GlobalKnownHostsFile 或服务端没设 TrustedUserCAKeys，证书就形同虚设。一次配准，后续增删节点或人员，只需签新证、删旧证，无需改任何配置文件或手动 touch known_hosts。
