“远程主机密钥改变”本质是openssh因本地~/.ssh/known_hosts中存储的公钥与服务器当前出示的不一致而拒绝连接，主因包括服务器重装、ip复用、proxyjump跳转误校验或wsl/windows双环境混用known_hosts文件。
VSCode报“远程主机密钥改变”，本质是OpenSSH在拒绝一次不安全的连接尝试——它发现你本地~/.ssh/known_hosts里存的公钥，和当前服务器实际出示的不一致。这不是VSCode的bug，也不是服务器被黑了（大概率），而是你连过那台机器，现在它的SSH密钥换了。
为什么known_hosts会“对不上”
常见但容易被忽略的几类原因：
- 服务器重装系统（云平台一键重置、手动重装、Docker容器重建）→ 生成全新
HostKey - IP地址复用：旧服务器下线后，同一IP分配给新机器，但
known_hosts还记着老主机的指纹 - 启用了
ProxyJump跳转，实际校验的是跳板机的密钥，不是目标机——删错行就白忙 - Windows + WSL用户混用两套
known_hosts：PowerShell用%USERPROFILE%\.ssh\known_hosts，而VSCode调用的是WSL里的/home/username/.ssh/known_hosts，改了A却在B里连
删哪一行？用ssh-keygen -R还是手动编辑
推荐优先用命令清理，精准且不易误操作：
GitHub Hosts CN
下载
GitHub Hosts 更新工具（仅限中国用户），安全更新系统hosts文件，保留原有非GitHub条目，仅替换GitHub相关地址。支持备份恢复和风险提示。用于解决GitHub访问问题。
- 确认你在VSCode Remote-SSH配置里写的是什么主机标识（比如
192.168.1.100、myserver或host.example.com） - 在终端运行：
ssh-keygen -R 192.168.1.100（把IP或域名替换成你实际用的） - 别用
ssh-keygen -R *清空全部——生产环境连几十台机器，全删完下次每台都要手动确认，反而更卡 - 如果
known_hosts里某一行含多个主机（用空格分隔），手动删时务必只删目标部分，否则可能连错其他主机
删完还是报错？检查三个隐藏位置
清理known_hosts后仍失败，说明有缓存或路径没对上：
- VSCode Remote-SSH插件自身缓存：关掉VSCode，删掉
~/.vscode-server（Linux/macOS）或~/.vscode-remote（部分Windows+WSL场景） - 如果你用了
ProxyJump，错误实际来自跳板机——要删的是跳板机的记录，不是最终目标机的 - Windows用户从桌面图标启动VSCode，默认走PowerShell环境；但从WSL终端执行
code .，则走WSL的SSH配置。用which ssh和ls -l ~/.ssh/known_hosts确认当前环境读的是哪个文件
临时跳过验证只该用在哪种场景
仅限你100%确定环境可信时才考虑，比如本地虚拟机、公司内网测试机：
- 在
~/.ssh/config对应Host段加两行：StrictHostKeyChecking no+UserKnownHostsFile /dev/null（缺一不可） - 别只加
StrictHostKeyChecking no——OpenSSH仍会读默认known_hosts并报错 - 这个组合等于彻底关闭主机身份校验，公网服务器禁用；用完建议立刻切回正常模式
最稳妥的长期方案其实是用ssh-keyscan手动更新密钥：先ssh-keygen -R host，再ssh-keyscan -t ed25519 host >> ~/.ssh/known_hosts。这样既不牺牲安全性，又避免每次重连都手动确认——但前提是你要清楚服务器支持哪种密钥类型（rsa、ed25519还是ecdsa），这点容易被跳过。
