“host key verification failed” 怎么办？SSH/Git 疑难解答 – wiki基地

作者： /

深入解析与应对：SSH/Git 中的 “Host Key Verification Failed” 疑难解答

在使用 SSH（Secure Shell）协议连接远程服务器，或者通过 SSH 协议进行 Git 操作（如 git clone, git pull, git push）时，你可能会遇到一个令人困惑且常见的错误信息：“Host key verification failed.”。这个错误直接阻止了你与远程主机的连接或交互，对于初学者乃至一些有经验的用户来说，都可能造成困扰。

本文旨在深入剖析这个错误背后的机制、产生原因，并提供一套系统、详尽的解决方案和最佳实践，帮助你彻底理解并有效处理 “Host Key Verification Failed” 问题。本文篇幅较长，力求覆盖各种场景和细节，助你成为 SSH 连接的排错专家。

一、 理解核心机制：什么是主机密钥（Host Key）及其验证过程？

要解决问题，首先必须理解问题本身。SSH 协议的设计核心之一就是安全性，特别是在首次连接到一个未知服务器时，如何确保你连接的是目标服务器，而不是一个伪装的、恶意的中间人（Man-in-the-Middle, MitM）？

这就是主机密钥（Host Key）发挥作用的地方。

  1. 主机密钥的生成与存在：

    • 每一台运行 SSH 服务（SSHD, Secure Shell Daemon）的服务器，在首次启动或配置时，都会自动生成（或由管理员手动生成）一对或多对密钥对（公钥和私钥）。这些密钥对通常存储在服务器的 /etc/ssh/ 目录下，文件名类似于 ssh_host_rsa_key（私钥）和 ssh_host_rsa_key.pub（公钥），也可能是 ECDSA、ED25519 等其他算法的密钥。
    • 这些密钥对是特定于该服务器实例的。服务器的公钥（Host Public Key）会向任何尝试连接它的 SSH 客户端展示。

  2. 首次连接与信任建立：

    • 当你第一次使用 SSH 客户端（如 ssh 命令行工具、PuTTY、Git Bash 等）连接到一个新的服务器时，该服务器会将其主机公钥发送给你的客户端。
    • 你的 SSH 客户端会提示你，它不认识这个服务器的主机密钥，并显示该密钥的指纹（Fingerprint）——一个由公钥生成的、更易于人类比较的短哈希值。
    • 此时，客户端会询问你是否信任这个密钥并希望继续连接（通常显示类似 “Are you sure you want to continue connecting (yes/no/[fingerprint])?” 的提示）。
    • 关键步骤： 在理想情况下，你应该通过一个带外（Out-of-Band）的方式（例如，询问服务器管理员、查看官方文档、通过安全的内部渠道获取）来验证这个指纹是否确实属于你想要连接的目标服务器。
    • 如果你选择 yes，你的 SSH 客户端会将该服务器的主机名（或 IP 地址）及其对应的主机公钥记录在一个名为 known_hosts 的文件中。这个文件通常位于你的用户主目录下的 .ssh 文件夹内（即 ~/.ssh/known_hosts）。

  3. 后续连接与验证：

    • 当你再次连接到同一个服务器（基于其主机名或 IP 地址）时，SSH 客户端会执行以下验证：

      • 服务器再次发送其主机公钥。
      • 客户端在 known_hosts 文件中查找之前为该主机名/IP 记录的公钥。
      • 比较： 客户端比较服务器当前发送的公钥与 known_hosts 文件中记录的公钥是否完全一致。
      • 成功： 如果两者匹配，验证通过，连接继续进行，通常不再有任何提示（这是正常的、安全的状态）。
      • 失败： 如果两者不匹配，SSH 客户端会认为连接可能不安全——要么是服务器的身份发生了变化，要么可能存在 MitM 攻击。此时，客户端会拒绝连接，并显示 “Host key verification failed.” 或类似的警告信息，例如：

      @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
      @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
      @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
      IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
      Someone could be eavesdropping on you right now (man-in-the-middle attack)!
      It is also possible that a host key has just been changed.
      The fingerprint for the ECDSA key sent by the remote host is
      SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
      Please contact your system administrator.
      Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
      Offending ECDSA key in /home/user/.ssh/known_hosts:15 <-- 注意这一行！
      ECDSA host key for example.com has changed and you have requested strict checking.
      Host key verification failed.

二、 “Host Key Verification Failed” 的常见原因

理解了验证过程后，我们就容易推断出导致验证失败的常见原因：

  1. 服务器重装或系统升级： 这是最常见的原因。当服务器的操作系统被重新安装，或者 SSH 服务被重新配置时，通常会生成新的主机密钥。旧的密钥丢失，新的密钥与你本地 known_hosts 文件中记录的不符。
  2. 服务器主机密钥变更： 服务器管理员可能出于安全或其他原因，手动重新生成了主机密钥。
  3. 服务器迁移或 IP 地址/主机名变更：
    • 如果服务器迁移到了新的硬件或虚拟机，即使配置相同，也可能生成了新的主机密钥。
    • 如果服务器的 IP 地址改变了，而你仍然使用旧的 IP 地址连接，或者某个旧的 IP 地址被分配给了另一台完全不同的服务器，当你尝试用该 IP 连接新服务器时，其主机密钥自然与 known_hosts 中为该 IP 记录的（旧服务器的）密钥不匹配。主机名同理。
  4. 网络环境变化：
    • 负载均衡器/代理： 如果你通过负载均衡器或透明代理连接服务器，而这些中间设备的配置发生变化，或者后端服务器轮换导致你连接到了一个具有不同主机密钥的新实例，可能会触发此错误。
    • DNS 缓存问题或 DNS 劫持： 虽然少见，但如果 DNS 解析将主机名指向了错误的 IP 地址（可能是缓存问题，也可能是恶意的 DNS 劫持），你实际上在尝试连接一个非预期的服务器，其密钥自然不匹配。
  5. known_hosts 文件本身的问题：
    • 文件损坏： 极少数情况下，known_hosts 文件可能损坏。
    • 错误的条目： 可能之前手动编辑时引入了错误，或者记录了多个冲突的条目。
    • 权限问题： ~/.ssh/known_hosts 文件权限不正确也可能导致读取失败，虽然错误信息可能不同，但也值得检查。
  6. 使用不同的标识符连接同一服务器： 例如，你第一次使用 IP 地址 192.168.1.100 连接并接受了密钥，后来又使用主机名 server.local 连接同一台服务器。如果 SSH 客户端配置（或默认行为）没有将两者关联，它可能会将 server.local 视为一个新主机，并要求接受密钥。反之，如果 known_hosts 中同时存在 IP 和主机名的条目，但服务器因为某种原因（比如 IP 变了但主机名没变）只更新了其中一个对应的密钥，也可能导致使用另一个标识符连接时失败。
  7. 真正的中间人攻击（MitM）： 这是主机密钥验证机制旨在防范的最严重情况。攻击者在你的网络路径上拦截了你的 SSH 连接，并伪装成目标服务器，向你呈现它自己的（伪造的）主机密钥。如果你不加验证就接受了攻击者的密钥，你的后续通信（包括密码、命令等）都可能被窃听或篡改。虽然这个原因相比前几种可能性小，但绝不能忽视其风险。

三、 详细的故障排除步骤

遇到 “Host key verification failed.” 错误时，切忌直接盲目地删除 known_hosts 条目。首要原则是：确认服务器身份的改变是预期的、合法的。

以下是推荐的排错步骤：

步骤 1：仔细阅读错误信息

错误信息通常包含了关键线索。注意查找：

  • 警告级别： WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 表明密钥确实变了。
  • 风险提示： IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! 强调了 MitM 的可能性。
  • 新密钥指纹： The fingerprint for the XXX key sent by the remote host is SHA256:xxxxxxxx... 这是服务器当前提供的新密钥指纹。
  • 冲突位置： Offending XXX key in /home/user/.ssh/known_hosts:15 这非常重要！ 它指明了 known_hosts 文件中与当前连接尝试冲突的具体行号（示例中是第 15 行）。
  • 主机标识： XXX host key for example.com has changed... 指明了你尝试连接的主机名或 IP 地址。

步骤 2：验证新主机密钥的真实性 (安全关键！)

在你对 known_hosts 文件做任何修改之前，必须尽可能确认服务器主机密钥的变更是否正常。

  • 联系服务器管理员： 如果是公司或团队的服务器，立即联系负责的管理员。询问服务器最近是否有维护、重装、迁移或密钥更新。让他们提供当前正确的主机密钥指纹。
  • 通过可信通道获取指纹：
    • 物理访问/控制台： 如果你能物理访问服务器或通过带外管理（如 KVM、iDRAC、ILO）登录到服务器控制台，可以执行以下命令查看服务器当前的主机公钥指纹：
      bash
      # 查看所有公钥的指纹 (推荐使用 SHA256)
      ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
      ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
      ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub
      # 或者更方便地，一次性列出所有可用密钥指纹
      sshd -T | grep hostkeyalgorithms | awk '{print $2}' | xargs -I{} ssh-keygen -l -f /etc/ssh/ssh_host_{}_key.pub
      # 在某些系统上，可能更简单：
      ssh-keyscan -t rsa,ecdsa,ed25519 localhost | ssh-keygen -lf -
      将输出的指纹与错误信息中显示的新指纹进行比对。
    • 可信同事/文档： 如果是共享服务器，询问信任的同事是否也遇到了同样的问题，并确认他们获取的新指纹是否一致。或者查阅可靠的内部部署文档。
  • 谨慎使用 ssh-keyscan： ssh-keyscan <hostname_or_ip> 命令可以从远程服务器获取其主机公钥。但是，请注意： 如果你直接在不安全的网络环境（比如公共 Wi-Fi）下运行 ssh-keyscan，它本身也可能受到 MitM 攻击，从而获取到攻击者的伪造密钥。因此：
    • 最好在已知安全的网络环境下运行 ssh-keyscan。
    • ssh-keyscan 获取到的密钥应该与其他可信来源（如管理员提供）的指纹进行交叉验证。
    • ssh-keyscan 的一个安全用途是在确认密钥变更合法后，用它来自动更新 known_hosts 文件（见后文）。

只有当你确信服务器主机密钥的变更是合法且预期的（例如，确认了服务器重装），或者你已经通过可靠途径验证了新指纹的真实性后，才进行下一步。如果你有任何怀疑，或者无法验证，请停止连接并寻求帮助，直到确认安全为止。

步骤 3：移除 known_hosts 文件中的旧/冲突条目

确认新密钥合法后，你需要移除 known_hosts 文件中记录的旧的、导致冲突的主机密钥条目。推荐使用以下方法：

  • 方法一：使用 ssh-keygen -R (推荐)
    这是最安全、最简单的方法。ssh-keygen -R 命令专门用于从 known_hosts 文件中移除指定主机的所有密钥条目。
    打开你的终端（或 Git Bash），执行：

    bash
    ssh-keygen -R <hostname_or_ip>

    将 <hostname_or_ip> 替换为错误信息中提示的主机名或 IP 地址（例如 example.com 或 192.168.1.100）。

    这个命令会自动找到并删除 ~/.ssh/known_hosts 文件中与该主机相关的所有行。它通常还会备份原始文件。

    示例：
    “`bash
    ssh-keygen -R example.com

    或者

    ssh-keygen -R 192.168.1.100
    “`

    如果错误信息中明确指出了冲突的行号（如 Offending ... key in ...:15），ssh-keygen -R 也能处理这种情况。

  • 方法二：手动编辑 known_hosts 文件 (需谨慎)
    如果你想更精细地控制，或者 ssh-keygen -R 因故无法使用，可以手动编辑 ~/.ssh/known_hosts 文件。

    1. 使用文本编辑器打开文件：nano ~/.ssh/known_hosts 或 vim ~/.ssh/known_hosts。
    2. 找到错误信息中提示的冲突行号（例如第 15 行）。
    3. 删除该行。
    4. 注意： known_hosts 文件中的每一行通常包含：主机名/IP（可能多个，逗号分隔）、密钥类型（如 ssh-rsa, ecdsa-sha2-nistp256）、以及 Base64 编码的公钥本身。
    5. 注意哈希主机名 (Hashed Hostnames)： 如果你的 SSH 配置中启用了 HashKnownHosts yes（这是现代 SSH 的默认设置），known_hosts 文件中的主机名部分会被哈希处理，看起来像一串乱码（以 |1| 开头）。这使得你无法通过直接搜索主机名来定位条目，也让手动编辑变得困难且容易出错。错误信息中提示的行号在这种情况下至关重要。如果你看到的是哈希条目，强烈建议使用 ssh-keygen -R。
    6. 保存并关闭文件。

步骤 4：重新连接并接受新密钥

移除了旧的冲突条目后，再次尝试连接服务器：

“`bash
ssh user@

或者对于 Git:

git clone git@:repository.git

或者 git pull / git push 等

“`

此时，由于 known_hosts 中已没有关于该主机的记录，SSH 客户端的行为将如同首次连接：

  • 它会显示服务器发送过来的新主机密钥的指纹。
  • 它会询问你是否信任并继续连接 (yes/no/[fingerprint])?。

关键时刻：
* 再次核对！ 将屏幕上显示的指纹与你在步骤 2 中通过可信方式验证过的指纹进行最后一次比对。
* 确认无误后，输入 yes。

SSH 客户端会将新的、正确的服务器主机密钥添加到你的 ~/.ssh/known_hosts 文件中。连接应该就能成功建立，后续的连接（只要服务器密钥不再改变）也将恢复正常。

四、 进阶场景与考量

  1. StrictHostKeyChecking 选项：
    SSH 客户端配置（通常在 ~/.ssh/config 或全局 /etc/ssh/ssh_config）中有一个 StrictHostKeyChecking 选项，它控制着对未知或已更改主机密钥的处理方式：

    • StrictHostKeyChecking yes (或 on): 这是最安全、也是通常的默认设置（尤其在现代系统中）。如果主机密钥未知或发生变化，立即拒绝连接并报错（即我们讨论的 “Host key verification failed.” 情况）。
    • StrictHostKeyChecking no (或 off): 极其不推荐！ 这会完全禁用主机密钥检查。客户端会自动将任何新密钥添加到 known_hosts 文件，不会提示用户，也不会在密钥变化时发出警告。这使得 MitM 攻击变得非常容易，严重破坏了 SSH 的安全性。除非你有非常特殊且明确的理由，并完全理解其风险，否则永远不要设置为 no。
    • StrictHostKeyChecking ask (或 prompt): 这是较旧系统或某些配置下的默认值。首次连接未知主机时，会提示用户是否接受密钥 (yes/no)。如果主机密钥发生变化，它通常也会报错并拒绝连接（行为类似 yes）。
    • 在排错时，不要为了“快速解决”问题而将此选项设置为 no。正确的做法是遵循上述步骤，验证并更新密钥。

  2. 自动化环境与脚本：
    在自动化脚本（如 CI/CD 流水线、部署脚本）中处理主机密钥变更可能比较棘手，因为没有人工交互来确认。

    • 预先填充 known_hosts： 在运行脚本的环境中，可以预先将目标服务器的已知、可信的主机密钥添加到 known_hosts 文件中。
    • 谨慎使用 ssh-keyscan： 可以在脚本开始时，通过安全的网络连接运行 ssh-keyscan <hostname_or_ip> >> ~/.ssh/known_hosts 来添加或更新密钥。但如前所述，要确保 ssh-keyscan 本身获取密钥的过程是安全的。
    • 禁用严格检查（风险自负）： 有时为了方便，人们会在脚本中临时使用 -o StrictHostKeyChecking=no 选项。再次强调，这有严重的安全风险，只应在完全受控、内部、可信的网络环境中，且你完全明白后果时才考虑。更好的做法是管理好主机密钥。
    • 使用 UserKnownHostsFile=/dev/null： 这个选项告诉 SSH 不要使用任何 known_hosts 文件，并且与 StrictHostKeyChecking=no 结合使用时，它会连接但不记录任何密钥。这同样非常不安全，因为它完全绕过了主机验证。

  3. Git 操作中的错误：
    当你在使用 Git（如 git clone, git pull, git push）且远程仓库 URL 是 SSH 格式（例如 [email protected]:user/repo.git 或 ssh://[email protected]/path/to/repo.git）时遇到 “Host key verification failed.”，其原因和解决方法与直接使用 ssh 命令完全相同。因为 Git 底层正是调用了 SSH 客户端来建立连接。按照上述步骤处理 ~/.ssh/known_hosts 文件即可。

五、 预防措施与最佳实践

  • 沟通： 如果你是服务器管理员，在计划进行任何可能导致主机密钥变更的操作（如重装系统、更换硬件、更新 SSH 配置生成新密钥）之前，务必提前通知所有需要连接该服务器的用户，并提供获取新密钥指纹的安全途径。
  • 使用一致的主机标识符： 尽量始终使用相同的方式（例如，总是使用完全限定域名 FQDN）来连接服务器，避免因混用 IP 和主机名导致 known_hosts 中出现多个可能冲突的条目。可以通过 ~/.ssh/config 文件为常用主机设置别名和首选连接方式。
  • 理解 ~/.ssh/config： 学习使用 ~/.ssh/config 文件可以简化连接，并允许你为特定主机定制选项（包括 StrictHostKeyChecking，虽然不建议轻易修改）。
  • 定期审查 known_hosts（可选）： 对于高度敏感的环境，可以偶尔检查 known_hosts 文件，移除不再使用的主机条目，但这通常不是必需的。
  • 永远不要盲目接受未知密钥： 养成验证指纹的习惯。如果 SSH 提示密钥未知或已更改，花几分钟时间去确认，这是保障连接安全的关键一步。

六、 总结

“Host key verification failed.” 错误本质上是 SSH 的一个核心安全特性在发挥作用，它保护你免受潜在的中间人攻击。遇到这个错误时，正确的应对流程是：

  1. 理解错误信息，找到冲突点。
  2. 验证新密钥的真实性（通过管理员、控制台或其他可信渠道）。
  3. 在确认新密钥合法后，使用 ssh-keygen -R <hostname_or_ip> 移除旧的冲突条目。
  4. 重新连接，仔细核对显示的指纹无误后，接受新密钥。

切勿为了图方便而牺牲安全（例如，禁用 StrictHostKeyChecking）。通过遵循本文提供的详细步骤和最佳实践，你不仅能解决当前的连接问题，更能加深对 SSH 安全机制的理解，从而在未来的使用中更加自信和安全。

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部