服务器刚重装完，SSH 却提示 REMOTE HOST IDENTIFICATION HAS CHANGED!，连接随即中断。重装确实可能生成新的主机密钥，但同一个警告也可能来自 IP 被重新分配、域名指向错误，甚至连接被冒充。只有从独立可信渠道核对新指纹后，才适合更新本机记录。
直接删除整个 known_hosts，或关闭主机密钥检查，虽然可能让连接继续，却会丢掉判断服务器身份的重要依据。本文按“确认连接目标、取得可信指纹、更新特定记录、重新验证”的顺序处理，适用于 Linux、macOS 和 Windows OpenSSH 客户端。PuTTY 等图形客户端的密钥缓存位置不同，不应直接套用文件操作命令。
这个警告检查的是什么密钥
SSH 服务器用主机密钥证明自己的身份，客户端通常把已信任的公钥保存在 known_hosts。再次连接时，如果服务器提供的密钥与旧记录冲突，客户端就会告警或拒绝连接。[1]
它与用于登录的用户密钥分属两件事：
| 项目 | 用途 | 常见位置 |
|---|---|---|
| 服务器主机密钥 | 让客户端验证服务器身份 | 服务端 /etc/ssh/ssh_host_*，实际路径以配置为准 |
| 客户端用户密钥 | 让服务器验证登录用户 | 客户端私钥与服务端 authorized_keys |
| known_hosts | 保存客户端已信任的主机公钥 | 客户端 ~/.ssh/known_hosts 等配置指定文件 |
因此，这个错误通常不需要重新生成自己的登录私钥，也不需要清空服务器的 authorized_keys。修改这些文件可能额外造成登录故障。
留下完整报错，核对连接的是哪台服务器
记录警告中的目标、端口、密钥类型、SHA256 指纹，以及冲突文件与行号。文件路径可以帮助定位记录，但不要仅凭行号就删除。
常见正常变更包括重装系统、管理员主动轮换主机密钥，以及旧 IP 分配给另一台实例。域名改了记录、SSH 配置指向跳板机或代理，也会改变实际连接对象。
先核对云平台中的实例 ID、公网 IP、重装记录和操作时间，再查看客户端有效配置。下面的域名与端口均为示例，须替换为实际值：
ssh -G -p 2222 ops@example.com
重点关注 hostname、port、hostkeyalias、userknownhostsfile、globalknownhostsfile、proxyjump 和 proxycommand。用 SSH 别名连接时，应对该别名执行 ssh -G，因为别名可能带有不同目标、端口和密钥文件。
必要时使用 ssh -v 查看连接过程，但不要把包含内部域名、用户名或网络拓扑的完整日志公开发布。检查 DNS 解析可以发现目标变化，却不能独立证明新服务器身份；受影响的连接路径本身也可能提供错误结果。
没有预期内的重装或换钥记录，或者实例 IP 与目标不符时，应停止连接，交由管理员核查。 不要继续输入密码或接受新密钥。
从云控制台或可信管理渠道取得新指纹
可通过已经确认身份的云平台控制台、串口控制台，或既有可信管理通道进入目标实例。在服务端读取实际使用的主机公钥指纹：
sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256
如果警告显示的是 RSA 或 ECDSA，应查询对应公钥文件。例如：
sudo ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub -E sha256
sudo ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub -E sha256
并非每台服务器都存在这些文件。若 sshd 使用自定义配置、其他 HostKey 路径、容器内服务或端口转发，应查清最终处理该端口的 sshd 实例。默认情况下，可用以下命令查看主机密钥配置：
sudo sshd -T | grep -i '^hostkey '
使用非默认配置启动的实例，还需匹配实际配置参数。公钥文件可以用于核验，不要上传、粘贴或传输不带 .pub 后缀的主机私钥。
把可信渠道取得的 SHA256 指纹，与客户端本次警告或连接提示展示的指纹逐字核对，密钥算法也必须一致。ED25519 与 RSA 的指纹本来就不同，不能跨算法比较。若服务器使用主机证书，应按照组织的 SSH CA 与证书验证流程处理，不宜改成临时信任一把裸公钥。
为什么 ssh-keyscan 不能独立完成核验
ssh-keyscan 可以采集目标端口当前提供的公钥，但它不会自动证明对方身份。OpenSSH 手册明确提示，未核验就用其结果构建 known_hosts，会面临中间人攻击风险。[3]
# 只采集当前网络端点的 ED25519 公钥，暂存用于比较
ssh-keyscan -p 2222 -t ed25519 example.com > candidate-host-key.txt
ssh-keygen -lf candidate-host-key.txt -E sha256
这份结果只有与独立可信渠道提供的同算法指纹一致后，才有信任依据。不要执行未经核验的 ssh-keyscan ... >> ~/.ssh/known_hosts。网络上拿到的两个相同结果，也不能替代独立身份核验。
核验通过后，只更新该目标的旧记录
以下命令在客户端执行。默认端口的查找键通常为域名或 IP；非默认端口通常采用 [主机]:端口 格式。使用 HostKeyAlias、自定义 known_hosts 文件或组织集中管理时，应依据有效配置和告警确定实际存储键与文件。[2][4]
Linux、macOS 或其他类 Unix Shell 示例：
cp -p ~/.ssh/known_hosts ~/.ssh/known_hosts.bak.$(date +%Y%m%d-%H%M%S)
ssh-keygen -F '[example.com]:2222' -f ~/.ssh/known_hosts
ssh-keygen -R '[example.com]:2222' -f ~/.ssh/known_hosts
-F 用于查找，-R 删除与指定主机键匹配的记录，也支持散列主机名。[2] 它可能删除这个目标下的多种密钥类型，并非只删警告中的一行；应先查看匹配内容并保存备份。不要对所有主机执行批量清理。
Windows PowerShell 使用对应的客户端路径：
$kh = Join-Path $HOME '.ssh\known_hosts'
Copy-Item -LiteralPath $kh -Destination ($kh + '.bak.' + (Get-Date -Format 'yyyyMMdd-HHmmss'))
ssh-keygen -F '[example.com]:2222' -f $kh
ssh-keygen -R '[example.com]:2222' -f $kh
默认 22 端口一般使用 example.com；直接连 IP 则使用实际 IP。如果域名和 IP 都存有旧记录，应分别核查各自对应的端点。不要看到相似地址就一并删除。
若冲突记录来自系统级文件或组织配置，应由有权限的管理员更新，避免只修改个人文件后仍被旧记录拦截。也不要把全局信任文件复制成个人文件来绕过管理策略。
重新连接时，仍要比较提示中的指纹
完成目标记录更新后，使用正常主机校验模式重连：
ssh -o StrictHostKeyChecking=ask -p 2222 ops@example.com
只有提示中的算法和指纹与已核验结果一致时，才接受并保存。若仍提示冲突，应检查实际使用的记录文件、端口、别名和目标 IP，不要逐个文件清空尝试。
组织要求 StrictHostKeyChecking=yes 或集中分发信任记录时，应走原有管理流程，不能用上述 ask 示例覆盖组织策略。无交互的备份与部署任务，可由管理员提前分发已经核验的主机公钥，再保持严格校验。
不要把以下配置作为恢复方案：
StrictHostKeyChecking=no
UserKnownHostsFile=/dev/null
accept-new 能接受首次出现的主机密钥，但会拒绝已知主机的变更；它也无法替你确认首次连接的对象是否可信。[4] 此外，不要为了消除身份告警而全局启用陈旧算法。主机身份变更与算法协商失败是不同问题。
恢复后，在可信控制台核对实例身份、SSH 服务日志及登录记录。能成功登录只能说明认证通过，仍需确认登录的是预期实例。保留本次变更记录，包括实例、目标地址、端口、算法、新指纹、核验渠道和操作人。
指纹对不上，或更新后又变化怎么办
这时应保留原始告警、时间、DNS 结果和相关变更记录，停止对该端点发送凭据，并从可信控制台检查：
- DNS、负载均衡或转发是否把请求送到了不同实例。
- IP 是否发生重新分配，客户端别名是否仍指向旧环境。
- 重建流程是否反复生成主机密钥，或多个后端使用了不同身份。
- 是否存在未经授权的主机密钥变更或网络路径异常。
多实例共用一个 SSH 入口时，应设计稳定且可审计的身份验证方案，例如组织管理的主机证书，不能靠每次删除记录适应随机变化。
如果误删了本地记录，可以在确认备份内容与当前信任策略后，从备份恢复对应条目；恢复整个备份会覆盖其后新增的其他记录，需先比较差异。旧记录恢复后仍会拒绝已经合法换钥的服务器，因此它只能恢复本地配置，不能替代身份核验。
对于计划内重装，最好在变更前记录原指纹，重装后从控制台核对新指纹，再通知维护人员更新。主机私钥应纳入受控的安全管理；不要把同一份私钥随公共镜像分发给多台服务器。SSH 的这次拦截值得保留，修复应结束于确认身份和恢复严格验证。
参考资料
资料核验日期：2026 年 10 月 22 日。命令为示例，本文未声称在读者的生产环境完成测试。