SSH 主机密钥变更警告：先核对目标与指纹

SSH 连接出现 REMOTE HOST IDENTIFICATION HAS CHANGED!，说明这次服务器提供的主机密钥与客户端已有信任记录不一致。重装过 openssh-server、重建过虚拟机或更换过 IP，都不能代替对新指纹的确认。先通过独立可信的管理通道核对目标，再更新对应记录。

这是服务端主机身份检查，发生在用户密钥登录问题之前。修改自己的 id_ed25519 权限、重新生成客户端密钥或调整 authorized_keys，不能直接修复这项不一致。下面以普通 OpenSSH known_hosts 文件为例；主机证书、集中信任库和动态查询机制应按原有管理流程处理。

警告中的地址、端口和密钥类型都要对应

保留警告中的新指纹、密钥类型、冲突文件与行号，但不要先删那一行。先确认命令实际连接的主机名、地址和端口，以及跳板机或隧道的目标。IP 被重新分配、DNS 指向改变，或者端口转发到了另一台服务器，都可能让同一个连接名称遇到另一份主机密钥。

使用别名连接时，可只读展开客户端配置，下面名称是示例：

ssh -G app-server

关注 hostname、port、hostkeyalias、userknownhostsfile 和 globalknownhostsfile。平时传入 -F 等配置选项时，这次检查也要带上。HostKeyAlias 会改变信任记录使用的名称，因此不能只按命令行中的别名寻找条目。展开配置也不能证明 DNS 解析后连接的机器就是预期目标。

不使用 HostKeyAlias、且信任记录确实采用如下主机和非默认端口时，可在实际冲突文件中查找：

ssh-keygen -F '[server.example.com]:2222' -f ~/.ssh/known_hosts

这是查询记录，不建立远程连接，也支持哈希后的主机名。22 端口通常按主机名查找；用 IP 连接或配置另一个记录名时，应改成真正的键。查询不到，只说明这个文件里没有该键，不能证明其他信任文件没有冲突。

通过控制台读取服务器实际使用的公钥

从云平台控制台、机房控制台或已确认身份的管理通道进入目标服务器。查看 sshd 的有效 HostKey 配置，确认它实际读取哪些文件，而不是只看某个默认目录的修改时间。

如果警告对应 ECDSA，且服务端确实使用下面的公钥文件，可以在可信管理通道中查询指纹：

ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ecdsa_key.pub

路径和类型是示例，应按有效配置替换。比较时使用相同的密钥类型与指纹算法；Ed25519 指纹与 ECDSA 指纹本来就不同，MD5 与 SHA256 的显示也不能直接逐字比较。服务端主机私钥无需复制到客户端，更不能贴到聊天或日志里。

如果控制台确认的当前指纹与连接警告中的新指纹一致，并且目标地址、服务实例与变更记录都对应，才有理由按既定流程接受这次身份变更。它可能来自授权重建或轮换，也可能只是客户端遗留了以前另一台机器的记录。文件时间没变，不足以证明所有主机密钥都没变。

如果指纹不一致，先处理错误目标、代理转发或安全事件，继续保留旧信任记录。ssh-keyscan 能取得当前网络路径提供的公钥，却不能独立证明对方身份；把它的输出直接追加到 known_hosts，不能完成这一步核实。

重装软件是否重建主机密钥，取决于文件是否保留、安装方式和包处理。不要为了消除警告删除服务端全部密钥再生成；这会让其他客户端的信任记录也失效，并可能切断已有管理入口。

只在身份确认后更新对应记录

确认变更有效后，保存实际冲突文件的受限备份。下面仅用于当前用户的这个文件，并假定它采用所示主机与端口：

ssh-keygen -R '[server.example.com]:2222' -f ~/.ssh/known_hosts

这会移除该键下的所有密钥条目，不只是警告所列的一种密钥。先确认范围；同一地址承载多个逻辑目标时，应检查 HostKeyAlias 等配置是否正确区分身份。其他地址、全局信任文件或集中管理的记录不会因此自动修好。

随后按原有路线连接，对照刚从可信通道取得的指纹，按组织要求确认或登记新公钥。若 StrictHostKeyChecking 为 yes，需要按受控流程预先登记，而不是期待交互提示。accept-new 只自动接受新的主机记录，已有记录发生变化时仍会拒绝；关闭检查不能替代身份核实。

不要清空整个 known_hosts、改成忽略所有用户信任文件，或使用 sudo ssh 换一份信任库绕过提示。它们会扩大变化范围，并掩盖本来需要确认的目标不一致。

再次连接要确认同一目标和正常身份检查

验收包括原连接路线不再出现同一变更警告、服务器指纹与独立核对结果一致、正常主机检查仍启用，并且登录到预期机器与账号。用户认证若随后报 Permission denied，应单独检查客户端身份和服务端授权，不把这当成主机指纹修复失败。

若误改了其他目标的记录，可从备份恢复本次影响的条目；不要用旧备份重新信任已经撤销或确认泄露的密钥。旧服务器确实需要回退时，还须确认它的身份与安全状态，不能只恢复一行客户端文本就认为服务端已还原。