host key verification failed错误源于known_hosts中存储的主机公钥与当前服务器提供的不一致，多因服务器密钥轮换（如github 2023年rsa密钥更新）或内网git重装所致；应使用ssh-keygen -r精准删除对应条目后重新连接确认新指纹。
这是 SSH 连接 GitHub / GitLab 等远程仓库时的常见校验失败，不是密码或权限问题，而是本地 known_hosts 文件里存的主机公钥和当前服务器发来的不一致 —— 通常意味着服务器密钥变了，或你连到了假的主机（比如中间人攻击），但绝大多数情况是前者。
为什么 ssh -T git@github.com 会报这个错
SSH 客户端首次连接某主机时，会把它的公钥存进 ~/.ssh/known_hosts。下次再连，会比对服务端返回的公钥是否一致。如果不一致，就中止连接并报 Host key verification failed，这是安全机制，不是 bug。
- GitHub 曾在 2023 年 3 月轮换过 RSA 主机密钥（
github.com的 RSA 公钥指纹变了），老客户端没更新就会触发此错 - 公司内网 Git 服务器重装、更换 IP 或重置 SSH 服务后，密钥也会变
- 用了代理、跳板机或某些网络设备做 SSH 中继，也可能导致密钥不匹配
怎么安全地清理并重置 known_hosts 条目
别直接删整个 ~/.ssh/known_hosts（会丢失其他可信主机记录）。用 ssh-keygen -R 精准移除目标主机条目：
ssh-keygen -R github.com ssh-keygen -R gitlab.com ssh-keygen -R 192.168.1.100
执行后，再次运行 git pull 或 ssh -T git@github.com，SSH 会重新发起握手、提示你确认新密钥（显示 fingerprint），输入 yes 即可自动写入新记录。
- 如果提示 “No such file or directory”，说明该主机还没被记录过，问题不在这里
- 如果用的是非标准端口（如
ssh://git@host:2222/repo.git），要带端口清理：ssh-keygen -R [host]:2222 - Windows 上若用 Git Bash，路径和命令相同；若用 Windows OpenSSH（PowerShell），
known_hosts默认在$env:USERPROFILE\.ssh\known_hosts
如何避免反复手动确认（仅限可信内网环境）
开发机连内部 Git 服务器时，若密钥频繁变更且环境可控，可临时禁用严格校验（不推荐用于公网）：
git clone -c core.sshCommand="ssh -o StrictHostKeyChecking=accept-new" git@intranet:/repo.git
或全局配置（慎用）：
git config --global core.sshCommand "ssh -o StrictHostKeyChecking=accept-new"
-
accept-new：只接受从未见过的新主机密钥，已存在的仍校验；比no安全得多 - 绝不要设成
StrictHostKeyChecking=no—— 这等于关闭防中间人攻击能力 - 该配置不影响
ssh命令本身，只作用于 Git 调用的 SSH 过程
真正麻烦的不是删记录，而是分不清“该信”还是“不该信”。每次看到这个错，先用 ssh -vT git@host 看实际连接的是哪个 IP 和密钥指纹，再和官网公布的比对（GitHub 的指纹可在 GitHub 官方文档 查）。盲目 yes 或删文件，可能绕过本该起作用的安全护栏。
