定期轮换ssh密钥是生产环境强制要求，需区分用户密钥（建议90天轮换）与主机密钥（建议180天轮换），通过ansible等工具实现生成、分发、重启、验证、客户端信任同步的自动化闭环，并配套元数据记录、告警及审计机制。
Linux SSH 服务中的加密密钥不是一劳永逸的凭证，而是需要按明确周期和规则管理的动态资产。生命周期管理不到位，再强的算法也形同虚设；更新策略不闭环，轮换反而会引发连接中断或权限混乱。
区分两类密钥，分开制定策略
用户密钥和主机密钥承担不同角色，必须独立管理：
-
用户密钥（如
id_ed25519）：代表人或自动化身份，用于登录。每个用途（部署、监控、DB运维）应有专属密钥，禁止跨角色复用；建议每90天轮换一次，高敏系统可缩短至30天。 -
主机密钥（
/etc/ssh/ssh_host_*.key）：代表服务器自身指纹，客户端靠它验证目标是否真实。更换后所有已知主机记录失效，必须同步更新客户端信任列表；建议每180天轮换，避免长期暴露同一公钥哈希。
轮换必须自动化且可验证
手动逐台操作不可靠，应通过 IaC 工具（如 Ansible）驱动完整闭环：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 在控制节点统一生成新密钥对：
ssh-keygen -t ed25519 -f files/new_host_key -N ""，存入版本库。 - Playbook 使用
copy模块推送私钥（mode: '0600'）与公钥（mode: '0644'），确保属主为root:root。 - 重启前执行自检命令：
ssh -o ConnectTimeout=5 -o StrictHostKeyChecking=no localhost，失败立即中止。 - 分批执行（
serial: 3+delay: 10），防止集群级连接雪崩。
客户端信任必须同步更新
只换服务端密钥却不更新客户端，会导致 WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!，CI/CD 或监控任务可能卡死：
- 提前导出新指纹：
ssh-keygen -lf files/new_host_key.pub，获取类似256 SHA256:AbC user@host的结果。 - 用 Ansible 的
known_hosts模块精准替换目标主机条目，避免全量覆盖引发误删。 - 内网可信环境可临时启用
-o StrictHostKeyChecking=accept-new，但仅限首次连接且需配合审计日志。
配套机制决定策略能否落地
没有元数据、告警和审计，轮换只是形式主义：
- 每次轮换提交 Git，commit message 标注影响范围、旧/新指纹，例如
[HOST-KEY-ROTATE] web-01: from SHA256:xyz → SHA256:abc。 - 密钥文件启用
auditd监控：-w /etc/ssh/ssh_host_* -p wa -k ssh_host_keys。 - 设置提前7天告警，检查 CI 流水线、备份脚本、远程探针等是否仍引用旧密钥指纹。
- 保留最近3次主机密钥快照，配合
sha256sum校验完整性，支持快速回溯。
