实际使用与边界
适用场景：把警告当作一次变更管理事件：通过独立渠道取得新指纹，只删除准确的旧条目，并记录为何信任替换密钥。
边界：主机密钥变化可能来自合法重建，也可能来自拦截。本文无法替你验证基础设施；无法独立核验时应停止连接。
警告到底说明什么
SSH 会把服务器主机密钥的指纹记录在 known_hosts 中，之后连接时比较新旧密钥。如果同一个主机名或地址呈现了不同密钥，SSH 会在用户认证前停止，因为连接可能被拦截。警告本身不会告诉你变化是好是坏，只说明你原来信任的主机身份发生了变化。
常见的合法原因
云实例被重建、系统镜像重新生成主机密钥、公网 IP 被重新分配，或管理员按安全流程轮换密钥，都会触发警告。应把变更记录在维护工单、云控制台或部署输出中，不要仅凭记忆判断。
先验证，再清理
从服务器控制台、云串口、独立管理员渠道或已记录的配置管理输出中取得新指纹。比较算法和完整指纹，而不是文件名或截短字符串。如果无法独立验证，就停止连接；删除警告只会删除本地证据，不会让新主机变得可信。
只移除准确的旧记录
确认替换合法后，用 ssh-keygen -R 删除准确的主机名或地址条目。如果通过别名连接，也要检查别名和解析后的地址。哈希化的 known_hosts 记录可以交给工具处理，不要删除整个文件，以免丢失无关服务器的信任记录。
用窄范围测试重新连接
接受已核对的密钥后，先测试目标账户和一条无副作用的命令。正常使用应保持 StrictHostKeyChecking；accept-new 可以降低首次连接摩擦，但仍会拒绝已变化的密钥，也不能取代独立验证。
别漏掉端口、别名与主机证书
known_hosts 可能分别记录主机名、IP，以及用方括号表示的非默认端口。ProxyJump、堡垒机、DNS 别名和负载均衡也可能改变客户端实际验证的主机。删除前应检查详细连接输出，并用 ssh-keygen -F 查找匹配记录。如果环境使用 SSH 主机证书，应核对受信任的主机 CA 与证书 principal，而不是把它当作普通的一次性主机密钥。
在变更前后留下证据
记录警告中的旧指纹、通过独立渠道取得的新指纹、能够解释变化的基础设施事件、确认人或系统，以及首次成功连接的时间。完成后检查近期服务器认证和部署日志，寻找异常访问或计划外的密钥生成。IP 被回收时，新所有者可以解释指纹变化，却不能证明客户端本来就应该连接这台新机器，因此这一步尤其重要。
把它纳入变更管理
主机身份和用户认证解决的是不同问题：成功使用密码或公钥登录，并不能证明你连接的是预期机器。重建、迁移和密钥轮换都应有变更记录、恢复路径和回滚说明。
常见问题
能否直接运行 ssh-keygen -R？
只有先确认服务器重建、IP 复用或密钥轮换合法后才可以。否则可能擦掉重要的安全警告。
主机密钥变化意味着私钥泄露吗？
不一定。它首先涉及服务器主机身份，不自动代表客户端私钥泄露；但仍应调查基础设施变化和异常登录日志。
应该关闭 StrictHostKeyChecking 吗？
正常运行不应关闭。它可以隐藏身份变化并削弱拦截防护。