给 VPS 重装系统后，再次连接 SSH，终端可能不再进入登录界面，而是显示 REMOTE HOST IDENTIFICATION HAS CHANGED。也有人什么都没改，只是换了网络或使用域名连接，就遇到类似警告。此时最重要的不是让提示消失，而是确认：当前连接的服务器，是否仍然是自己准备访问的那一台。

正确顺序是暂停登录、核对目标、从独立可信渠道取得主机公钥指纹，确认变化有依据后再处理旧记录。本文以 OpenSSH 命令行客户端和 Linux 服务器为例，Windows 侧的命令使用 PowerShell。图形化 SSH 软件可能使用自己的主机记录库，不能把修改 OpenSSH 文件当作所有软件的通用修复。

这不是密码错误也不是普通超时

SSH 里有两种容易混淆的身份确认。服务器的主机密钥用来证明“你正在连接谁”；你自己的登录密钥或密码则用来证明“你是谁”。更换账户密码、重新生成个人登录密钥，并不能替代对服务器身份的核验。

RFC 4253 的服务器身份验证说明指出，客户端需要确认收到的公钥确实属于目标服务器；不验证就接受，会失去抵御主动攻击的重要保护。这里引用的是身份验证原则，不是推荐该早期 RFC 中列出的旧算法。

首次连接的“无法确认真实性”提示，通常意味着客户端尚未建立信任记录；“主机标识已经变化”则意味着当前密钥与已有记录不一致。两者都不适合不看内容直接输入 yes。而 Connection timed out、Connection refused 或 Permission denied (publickey) 又分别涉及其他连接或用户认证问题，不能统一用删除主机记录处理。

先把警告中的目标核对清楚

先退出这次连接，不输入密码、不上传文件。保存警告中的目标名称或 IP、SSH 端口、密钥算法、新指纹，以及冲突记录所在文件和行号。留在本机即可，公开求助时不需要把个人用户名、完整服务器清单和所有配置一起贴出。

接着核对自己的连接命令和服务商管理面板：IP 是否仍分配给同一实例，域名是否指向预期地址，端口是否仍映射到同一服务，最近是否重装过系统、重建过实例或做过主机密钥轮换。用了 SSH 别名或跳板机时，还要确认实际目标，不能只看一个熟悉的别名就认定无误。

重装、实例替换或地址重新分配，是需要调查的可能原因，不是自动接受新密钥的理由。普通重启本身也不足以解释密钥变化。如果管理面板没有任何对应变更，或者同一地址反复出现不同指纹，应停止登录并联系管理员或服务商核查，保留原记录。

从独立渠道核对同一种算法的指纹

最有帮助的是可信管理面板中的控制台、串行控制台或运行命令功能，以及管理员通过已确认渠道提供的主机公钥指纹。它们不应依赖这条正在报身份警告的 SSH 连接。管理面板本身也要确认来源，不能使用陌生私信里的“验证入口”。

微软的Linux 虚拟机 SSH 指纹核验示例说明了先通过门户运行命令获取指纹，再与客户端提示比较的做法。Azure 的按钮名称只适用于其平台；其他服务商要查看自己的控制台能力。

在自己有权限管理的 Linux 服务器可信控制台中，可以读取主机公钥文件的指纹。例如，提示对应 ECDSA 密钥时：

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

提示为 ED25519 时，应核对服务器实际使用的对应文件，而不是拿另一种算法的结果比较：

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

这些是读取公钥指纹的命令示例，不是生成新密钥的命令。路径因系统和服务配置而异；文件不存在时，向管理员确认实际的 HostKey 配置，不要为了得到一个结果重新生成服务器密钥。Windows SSH 服务器的密钥位置不同，不能照搬上述 Linux 路径。

比较时同时确认算法、指纹散列类型和完整值。ECDSA 与 ED25519 指纹不同是正常的；MD5 与 SHA256 的显示也不能直接比较。只有客户端提示的新指纹与可信渠道提供的对应指纹一致，且目标和变更原因都已核实，才进入下一步。

换一个网络重试、再次扫描服务器密钥，最多能获得当前路径返回的结果，不能替代独立身份核验。没有可信指纹来源，就保留警告并停止连接；“现在很急”不能使不可信的密钥变得可信。

核实之后才处理指定主机的旧记录

下面的步骤仅用于已经完成独立核验的 OpenSSH 用户。先根据警告确认实际使用的 known_hosts 文件。Windows 用户默认位置通常在用户目录的 .ssh 下，但配置可能指定其他文件；以当前客户端实际使用的路径为准。

先只查找，不修改。以下 server.example.invalid 和 2222 是示例，必须换成已核实的真实目标；若警告指向另一记录文件，也要更换文件路径：

$knownHostsFile = Join-Path $env:USERPROFILE '.ssh\known_hosts'
ssh-keygen -F '[server.example.invalid]:2222' -f $knownHostsFile

非默认端口采用方括号加端口的形式。通常使用默认端口 22 时，查询参数是主机名或 IP 本身。主机名、IP 和不同端口可能对应不同记录；不要因为没有查到其中一个，就一次清理所有形式。自定义 HostKeyAlias、集中管理的信任库或主机证书场景，应交由管理员按既定信任方式处理。

确认要处理的文件和主机后，先做一个不覆盖旧备份的副本：

$backupPath = $knownHostsFile + '.backup-' + (Get-Date -Format 'yyyyMMdd-HHmmss-fff')
if (Test-Path -LiteralPath $backupPath) { throw '备份文件已存在，请换一个文件名' }
Copy-Item -LiteralPath $knownHostsFile -Destination $backupPath -ErrorAction Stop

备份失败就停止，不继续修改。随后才移除该目标的旧记录：

ssh-keygen -R '[server.example.invalid]:2222' -f $knownHostsFile

-R 会移除该目标对应的密钥记录，可能不止一行；它不是只删除警告中某一个算法的公钥。它也不验证新密钥是否可信，因此核验不能放在删除之后。不要删掉整个 known_hosts，也不要改掉其他主机的记录、个人私钥或服务器的 authorized_keys。

重新连接时，仍应查看这次显示的算法与指纹，确认与刚刚独立核实的值一致，再按正常交互建立新记录。如果再次不一致，立即退出，不循环执行移除命令。微软前述说明也指出，主机密钥变化或旧记录移除后，会重新触发相关信任确认。

哪些做法不能当作修复

不要为了连接成功设置 StrictHostKeyChecking=no，不要把主机记录指向空设备，也不要照抄“自动接受所有指纹”的脚本。这些做法改变了身份核验的保护边界，却没有回答你到底连到了谁。

同样，不要把未经核实的密钥扫描结果直接追加进信任文件。扫描、显示指纹和独立验证是三件事；把网络上拿到的内容保存下来，不会自动赋予它可信来源。

公司服务器、共享管理设备或使用主机证书的环境，还可能由管理员统一维护信任记录。普通用户不应靠管理员权限强行修改集中配置，更不能生成一套新服务器密钥来消除本机提示。无法确认权限与流程时，提供脱敏后的错误类型、目标和发生时间，请管理员接手。

恢复后留下能解释变化的记录

核验通过后，记下实例标识、连接目标与端口、密钥算法、完整指纹、确认渠道、日期和变更原因。留存备份是为了审计与恢复误操作，不是下次出现新变化时直接恢复旧记录并继续登录；旧值同样需要与实际目标核对。

如果在核验之前已忽略警告并输入了密码，先停止继续连接，通过可信管理渠道联系管理员，按实际暴露的凭据处理。不能一概把主机密钥警告说成私钥已经泄露，也不能因为还能登录就判定没有风险。

这类问题与浏览器里的 TLS 证书报错不是同一套信任记录。HTTP 代理参数、清理浏览器缓存或更换 Clash 节点，都不能修复 SSH 主机身份不一致。需要区分普通网络路径故障时，可先看PowerShell 请求路径排查；但已经出现主机密钥变更警告，就应优先完成这里的身份核验。

最终要恢复的不只是一个能进入终端的连接，而是一个能够说明服务器身份为什么可信的连接。先确认目标与独立指纹，再备份和更新指定记录；无法确认时停下来，比把安全检查关闭更适合长期管理服务器。