Cursor / VS Code Remote-SSH 连接失败known_hosts「乱码」与主机密钥变更一次完整排障实录写在前面这不是一篇「复制命令就能好」的水文如果你正在用 Cursor、VS Code 的 Remote-SSH或者日常ssh登录云服务器大概率迟早会撞上这两类报错WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!Host key verification failed.更迷惑的是有时本地~/.ssh/known_hosts用编辑器一打开整页像「中文乱码」于是很多人第一反应是「文件坏了」。于是开始备份、重装客户端、换密钥、改端口折腾一圈问题依旧。这篇文章来自一次真实排障。我会把现象、误判、根因、修复步骤、安全边界以及为什么编辑器会显示乱码全部讲清楚。文中涉及的主机名、公网 IP、指纹、用户名均已脱敏你可以对照自己的环境复现思路而不是照抄敏感信息。目标读者用 Remote-SSH 远程开发的工程师运维 / 全栈日常连多台机器的同学重装过系统、换过云主机、IP 复用后突然连不上的人打开known_hosts发现「乱码」却不知从何下手的人预计阅读时间1520 分钟。建议收藏下次报错直接按目录跳转到对应章节。文章目录Cursor / VS Code Remote-SSH 连接失败known_hosts「乱码」与主机密钥变更一次完整排障实录写在前面这不是一篇「复制命令就能好」的水文一、事故现场Remote-SSH 秒失败日志却又臭又长二、先给结论两件事叠在一起别混为一谈三、为什么 SSH 要这么「小题大做」3.1 你信任的不是 IP而是「主机身份」3.2 主机密钥变更的常见「善意原因」3.3 也确实存在「恶意原因」四、日志逐行拆解Remote-SSH 到底卡在哪一步五、known_hosts「乱码」到底是什么用二进制一眼看穿5.1 为什么会被写成带 BOM 的样子六、完整修复流程Windows 为主Linux / macOS 同样适用步骤 0先确认「这是不是我预期中的变更」步骤 1备份步骤 2只删除冲突主机的旧记录推荐步骤 3修复文件编码若存在 BOM / 乱码观感步骤 4重新连接并核对指纹步骤 5回到 Cursor / VS Code 再连 Remote-SSH七、SSH config 常见搭配与排坑点八、安全边界什么时候能删什么时候不该删8.1 可以较快清理旧记录的场景8.2 应该警惕并停下来的场景8.3 不推荐的「粗暴疗法」九、深入一点为什么会提示 ECDSA实际却在谈 ED25519十、可复用的排障清单建议打印或存到团队 Wiki十一、扩展阅读known_hosts 的几种形态十二、一次「错误排障路径」对比「正确排障路径」错误路径真实世界里很常见正确路径十三、针对内容创作者与团队的脱敏建议十四、FAQ把评论区高频问题提前答掉十五、把经验沉淀成个人规范强烈建议十六、复盘时间线可当作案例模板十七、结语乱码是烟雾指纹才是枪声附录 A命令速查附录 B日志关键词中英文对照一、事故现场Remote-SSH 秒失败日志却又臭又长某天上午通过编辑器的 Remote-SSH 连接一台自建 Linux 服务器下文称dev-box配置大致如下已脱敏Host dev-box HostName 203.0.113.88 User deploy Port 22 IdentitiesOnly yes连接几乎瞬间失败。日志里能看到类似信息关键片段已整理敏感项替换Resolving ssh remote authority dev-box (attempt #1) Using configured platform linux for remote host dev-box Launching SSH server via shell with command: ... | ssh -T -D xxxxx dev-box bash --login -c bash Waiting for SSH handshake (timeout: 120s) 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 ED25519 key sent by the remote host is SHA256:AbCdEfGhIjKlMnOpQrStUvWxYz0123456789example. Please contact your system administrator. Add correct host key in C:\Users\you\.ssh\known_hosts to get rid of this message. Offending ECDSA key in C:\Users\you\.ssh\known_hosts:19 Host key for 203.0.113.88 has changed and you have requested strict checking. Host key verification failed.随后进程退出码255Remote-SSH 报Failed to connect to the remote SSH host. Error resolving SSH authority ...另外日志末尾还可能出现一段「中文乱码」式的 stderr在中文 Windows 上很常见看起来像管道相关错误。很多人会被这段吸引注意力以为是编码问题导致 SSH 挂了。稍后会说明那段多半是失败后的连带噪声不是根因。与此同时用编辑器打开C:\Users\you\.ssh\known_hosts内容呈现出大量「不可读字符」观感像文件损坏。于是「乱码」和「连接失败」被绑定成同一个锅——这正是误判的开始。二、先给结论两件事叠在一起别混为一谈这次问题其实是两层现象层 A连接失败的真因远程主机203.0.113.88的 SSH 主机密钥host key相对本地known_hosts中缓存的记录发生了变化。OpenSSH 开启严格主机密钥检查时会拒绝继续握手防止中间人攻击。层 B显示乱码的真因known_hosts文件被错误地带上了 UTF-16 LE 的 BOM字节序标记FF FE而文件主体内容仍是 ASCII / UTF-8 文本。编辑器看到 BOM 后按 UTF-16 解码于是正常的主机记录被「翻译」成乱码外观。文件未必逻辑全毁但观感极差也容易在二次编辑时进一步写坏。把两层拆开排障会立刻清晰要恢复连接处理过期 / 冲突的主机密钥记录。要恢复可读性与可维护性把known_hosts存回「无 BOM 的 UTF-8 / 纯 ASCII」并清理非法行。下面按「现象解释 → 原理 → 操作 → 风控 → 预防」展开。三、为什么 SSH 要这么「小题大做」很多人第一次看到IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!会觉得 OpenSSH 在吓唬人。其实这是 SSH 信任模型的核心3.1 你信任的不是 IP而是「主机身份」IP 可以漂移、复用、被劫持域名可以被解析到别处。SSH 用服务器持有的主机密钥对来证明「我还是上次那台机器」。客户端第一次连接成功后会把对方公钥以及对应的主机名 / IP写入known_hosts。以后再连同一目标时会核对对方出示的密钥是否与缓存一致不一致则报警并中断严格模式下。3.2 主机密钥变更的常见「善意原因」并非每次变更都是攻击真实环境里更常见的是云服务器重装系统sshd 重新生成了/etc/ssh/ssh_host_*密钥换了一台机器但弹性公网 IP / 域名没变运维主动轮换主机密钥合规或密钥泄露处置容器 / 临时环境每次启动都生成新密钥开发环境常见坑你连的其实是跳板或 NAT 后的不同后端。3.3 也确实存在「恶意原因」中间人伪造 SSH 服务DNS / 路由被污染流量被导向伪造节点内网里有人架了同名同端口的假服务。所以正确姿势不是「一律删掉 known_hosts 里所有东西」而是先确认这台机器是否刚重装 / 刚更换若有条件通过控制台、带外通道、云厂商面板核对新指纹再删除冲突的那一条或那一组旧记录重新连接并核对指纹后接受。四、日志逐行拆解Remote-SSH 到底卡在哪一步Remote-SSH 的工作流可以简化为解析Host别名如dev-box到真实HostName在本地拉起 askpass / 隧道相关辅助进程通过ssh -T等方式把安装脚本灌到远端部署 server 组件建立后续通信通道。本次失败发生在第 3 步之前的SSH 握手阶段连脚本都没机会在远端跑起来因为主机密钥校验已经失败。关键信号日志关键词含义REMOTE HOST IDENTIFICATION HAS CHANGED远端出示的主机密钥与本地缓存不一致Offending ... key in known_hosts:N冲突记录位于 known_hosts 第 N 行Host key for x.x.x.x has changed以 IP 为索引的记录发生变更strict checking严格检查开启拒绝「带病」继续Host key verification failed握手因身份校验失败而终止退出码255OpenSSH 客户端通用失败退出关于日志里偶发的「管道不存在 / 管道正在被关闭」类乱码信息在 Windows 上SSH 子进程异常退出后父进程仍尝试向已关闭的管道写数据控制台编码又不一致于是 stderr 呈现出乱码。它是「失败后的并发症」不是「因为管道坏了所以 SSH 失败」。排障时请优先盯住Host key verification failed。五、known_hosts「乱码」到底是什么用二进制一眼看穿不要只看编辑器渲染结果直接看文件头字节。正常的known_hosts一般是纯文本每行类似203.0.113.88 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... 203.0.113.88 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTY... github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...用十六进制查看时正常文件开头往往直接是主机名的 ASCII例如67 69 74 ...git...或数字 IP 的 ASCII。而「看起来乱码」的那份文件开头出现了FF FE ...FF FE是UTF-16 LE 的 BOM。更麻烦的是后面内容并没有真正按 UTF-16每个 ASCII 字符后跟00来存而是「BOM 仍为单字节 ASCII 正文」的混合体。于是按 UTF-16 打开满屏乱码按系统默认 ANSI / 某些错误编码打开同样灾难OpenSSH 在某些情况下仍可能「勉强」读到部分行取决于实现与脏数据分布于是你一边觉得文件坏了一边还看到「Offending key in line 19」——说明 SSH 其实读到了可用行号文件并非完全不可解析。此外脏文件里还可能混入孤立的非法字符行例如单独一个|多余空行半截被编辑器写坏的记录无意义的单字符行如单独的1。这些脏数据不一定立刻导致所有连接失败但会提高误判成本也会让后续用脚本批量维护时踩坑。5.1 为什么会被写成带 BOM 的样子常见触发路径用「记事本」打开后另存为编码选成 Unicode / UTF-16某些编辑器默认「UTF-16 LE with BOM」从网页 / 文档复制粘贴进 known_hosts再被错误编码保存自动化脚本用错了 .NET / PowerShell 的Unicode编码在 Windows 语义里Unicode常常就是 UTF-16 LE。记住一句很实用的话SSH 相关文本文件config、known_hosts、authorized_keys请始终使用UTF-8 无 BOM或纯 ASCII并使用 LF 或 CRLF 均可但不要用 UTF-16。六、完整修复流程Windows 为主Linux / macOS 同样适用下面给出一套可复用的标准动作。请按顺序做不要一上来删除整个known_hosts。步骤 0先确认「这是不是我预期中的变更」问自己三个问题这台服务器最近是否重装、迁移、更换镜像公网 IP / 域名是否可能指向了另一台机器是否有同事也在同一出口、同一时段遇到相同指纹变更如果答案明显是「刚重装」可以进入清理旧密钥流程。如果答案是「完全没动过却变了」先停走带外核对不要急着点 Accept。步骤 1备份在 PowerShell 中Copy-Item$env:USERPROFILE\.ssh\known_hosts $env:USERPROFILE\.ssh\known_hosts.bak-$(Get-Date-Format yyyyMMddHHmmss)在 bash 中cp~/.ssh/known_hosts ~/.ssh/known_hosts.bak-$(date%Y%m%d%H%M%S)步骤 2只删除冲突主机的旧记录推荐OpenSSH 自带官方做法ssh-keygen-R203.0.113.88如果known_hosts里同时存了域名和 IP两边都清ssh-keygen-R203.0.113.88 ssh-keygen-Rdev.example.com若使用了非 22 端口且记录写成了[host]:port形式ssh-keygen-R[203.0.113.88]:2222ssh-keygen -R的好处是只移除匹配目标保留 GitHub / 其他服务器记录避免「为了修一台机器把自己所有信任缓存清空」。步骤 3修复文件编码若存在 BOM / 乱码观感目标得到「无 BOM、合法行、可阅读」的known_hosts。PowerShell 示例思路逻辑说明可按需改写读取原始字节若开头是FF FE跳过 BOM按 ASCII / UTF-8 解码正文过滤空行、非法行删除目标 IP / 域名的旧记录若尚未用ssh-keygen -R以UTF-8 无 BOM写回。示意代码$path$env:USERPROFILE\.ssh\known_hosts$bytes[System.IO.File]::ReadAllBytes($path)$start 0if($bytes.Length-ge2-and$bytes[0]-eq0xFF-and$bytes[1]-eq0xFE){$start 2}$text[System.Text.Encoding]::UTF8.GetString($bytes,$start,$bytes.Length-$start)$lines$text-splitr?n|ForEach-Object{$_.Trim()}|Where-Object{$_-and($_-match^\S\s(ssh-|ecdsa-|sk-ssh-|sk-ecdsa-))}# 如需同时剔除某 IP$lines$lines|Where-Object{$_-notmatch^203\.0\.113\.88\s}$utf8NoBomNew-ObjectSystem.Text.UTF8Encoding$false[System.IO.File]::WriteAllText($path,(($lines-joinn)n),$utf8NoBom)写回后复查$b[System.IO.File]::ReadAllBytes($env:USERPROFILE\.ssh\known_hosts){0:X2} {1:X2}-f$b[0],$b[1]Get-Content$env:USERPROFILE\.ssh\known_hosts若开头不再是FF FE而是普通字母 / 数字的 ASCII说明编码已恢复正常。步骤 4重新连接并核对指纹命令行先测ssh-oStrictHostKeyCheckingask dev-box或sshdeploy203.0.113.88第一次会提示新的主机指纹。把提示中的SHA256:...与你从云控制台 / 服务器/etc/ssh侧拿到的指纹对比。一致再输入yes。在服务器上查看指纹需已有控制台或其它可信通道ssh-keygen-lf/etc/ssh/ssh_host_ed25519_key.pub ssh-keygen-lf/etc/ssh/ssh_host_ecdsa_key.pub ssh-keygen-lf/etc/ssh/ssh_host_rsa_key.pub步骤 5回到 Cursor / VS Code 再连 Remote-SSH命令行能通之后编辑器侧一般即可恢复。若仍缓存旧错误可重载窗口查看 Remote-SSH 输出面板确认不再出现IDENTIFICATION HAS CHANGED确认~/.ssh/config中Host、HostName、User、Port、IdentityFile无误。七、SSH config 常见搭配与排坑点一份干净的远程开发配置示例脱敏Host dev-box HostName 203.0.113.88 User deploy Port 22 IdentityFile ~/.ssh/id_ed25519_dev IdentitiesOnly yes ServerAliveInterval 30 ServerAliveCountMax 6说明IdentitiesOnly yes只使用你指定的私钥避免客户端把一串密钥轮流试导致远端Too many authentication failures。ServerAliveInterval降低长连接被中间设备掐断的概率。Windows 路径可用C:/Users/you/.ssh/id_ed25519_dev这种正斜杠写法兼容性更好。不要把私钥提交到 Gitconfig若包含内网别名注意分享范围。多个 Git 平台私钥并存时用Host别名拆分示例Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github IdentitiesOnly yes Host git.example.com HostName git.example.com User git IdentityFile ~/.ssh/id_ed25519_gitlab IdentitiesOnly yes这与本次主机密钥问题无直接关系但属于 Remote-SSH / SSH 日常稳定的「基础卫生」。八、安全边界什么时候能删什么时候不该删8.1 可以较快清理旧记录的场景你本人刚在云厂商控制台重装了系统迁移到新实例并确认 IP 复用测试机、可随时毁掉的环境团队内部已同步「主机密钥已轮换」通知并公布了新指纹。8.2 应该警惕并停下来的场景生产库所在主机无人宣布变更指纹与上周记录不一致且你无法通过带外渠道核验同一网段多台机器同时「集体换指纹」连接源网络不可信陌生 Wi-Fi、来路不明代理。8.3 不推荐的「粗暴疗法」直接删除整个known_hosts能「好」但会清空所有信任缓存放大风险面。永久关闭严格检查StrictHostKeyChecking no UserKnownHostsFile /dev/null这在一次性 CI 沙箱里或许权宜但放到个人主力开发机 / 生产运维机上等于关掉防中间人的安全带。3. 把报错当「编码问题」反复用记事本转码越转越脏。九、深入一点为什么会提示 ECDSA实际却在谈 ED25519日志里常见组合远端本次出示并提示的指纹是 ED25519同时写着Offending ECDSA key in known_hosts:N。这并不矛盾。一台 SSH 服务器通常同时持有多类主机密钥RSA / ECDSA / ED25519 等。客户端与服务端会协商使用哪一种。本地known_hosts里可能缓存了同一主机的多条不同类型记录。任意一条与当前策略下校验到的身份冲突都可能触发告警提示里的「Offending」指向的是本地缓存中被认为冲突的那条旧记录类型与行号而「fingerprint for the … key sent by the remote host」描述的是本次远端送来的那把钥匙。因此清理时最好删除该主机名 / IP 下的全部相关行而不是只删一种类型避免下一次又撞上另一类型的旧缓存。十、可复用的排障清单建议打印或存到团队 Wiki遇到 Remote-SSH / SSH 突然失败时按此清单执行先看退出点是 DNS、超时、权限还是Host key verification failed若是主机密钥变更记下 IP / 域名、行号、新指纹。确认变更是否预期重装迁移轮换备份 known_hosts。ssh-keygen -R host精确删除。检查 known_hosts 编码有没有FF FEBOM有没有非法行命令行ssh先打通再开编辑器 Remote-SSH。核对指纹后接受。若仍失败再查私钥、authorized_keys、安全组、sshd 配置、防火墙不要回头怀疑已经解决的 host key 问题。把「密钥身份问题」和「登录认证问题」分开是节省时间的关键。十一、扩展阅读known_hosts 的几种形态了解形态有助于读日志、写自动化。明文主机名 / IP 密钥类型 Base64 公钥最常见便于人工阅读。哈希主机名HashKnownHosts yes时主机名被哈希降低 known_hosts 泄露后的信息暴露但人工排查稍难删除时仍建议用ssh-keygen -R。带端口写法[203.0.113.88]:2222 ssh-ed25519 ...同一主机多算法多行完全正常。标记行 / 注释以#开头的注释在部分环境可用但不要依赖花哨格式保持简单最稳。团队若有机器农场可考虑集中分发可信known_hosts片段或使用证书认证SSH CA从根上减少「每台机器指纹漂移」带来的摩擦。那是后话值得单独写一篇。十二、一次「错误排障路径」对比「正确排障路径」错误路径真实世界里很常见打开 known_hosts看见乱码判断「文件坏了」用记事本另存为编码越存越奇怪删除私钥或重新生成客户端密钥对 host key 问题无效重装 Remote-SSH 扩展关闭防火墙、换网络最终仍失败浪费半天。正确路径读日志定位IDENTIFICATION HAS CHANGED确认服务器是否重装ssh-keygen -R删除旧记录顺便用二进制方式确认并去除错误 BOM命令行验证指纹后重连编辑器 Remote-SSH 恢复。同样的问题正确路径通常 10 分钟内结束。十三、针对内容创作者与团队的脱敏建议写排障文章、在群里求助、贴日志时请至少处理公网 IP →203.0.113.0/24文档专用示例网段或x.x.x.x域名 →dev.example.com用户名 →deploy/ops指纹 → 保留算法名替换中间字符本机路径中的真实用户名 →you内网网段、跳板机拓扑 → 必要时画示意图但隐去真实地址。脱敏不是掩饰问题而是避免把攻击面和资产地图无偿公开。CSDN / 博客平台文章被搜索引擎长期收录更要养成习惯。十四、FAQ把评论区高频问题提前答掉Q1删除 known_hosts 里某 IP 后会不会影响同一 IP 上的其他服务Aknown_hosts记录的是 SSH 主机身份不是 HTTP 服务。清的是 SSH 信任缓存。若该 IP 上 SSH 服务确实已换密钥这正是你要做的。Q2为什么我命令行能连编辑器不能连A常见原因包括编辑器使用的 ssh 与终端不是同一套、读的 config 路径不同、环境变量不同、仍缓存旧进程。以「同一 Host 别名在终端ssh Host」为金标准对齐。Q3提示变更但是我没重装怎么办A不要直接 Accept。登录云控制台 VNC / 串口核对ssh-keygen -lf指纹检查是否 IP 漂移到别的实例排查网络路径。Q4known_hosts 可以放进 Git 吗A不建议把个人完整 known_hosts 当普通代码提交。团队若要共享可信主机列表应单独维护精简白名单并走评审。Q5修复 BOM 后行数变少正常吗A正常。空行、非法行、目标主机旧密钥被清理后行数减少是预期结果。只要其他主机记录还在即可。Q6Windows 上到底该用哪种编码保存AUTF-8 无 BOM。不要选「Unicode」一词含糊的选项在微软生态里常指 UTF-16 LE。Q7Remote-SSH 安装 server 超时是一回事吗A不是。主机密钥失败通常在握手阶段秒失败安装超时发生在已建立 SSH 之后的脚本部署阶段。两者排查方向不同。Q8容器场景每次指纹都变怎么破A开发环境可对特定 Host 使用更宽松策略或固定容器内 host key 卷生产环境应固定密钥或改用证书体系而不是全局关闭检查。十五、把经验沉淀成个人规范强烈建议我建议每位经常连服务器的开发者给自己定四条硬规范只使用 UTF-8 无 BOM 维护~/.ssh下文本文件主机密钥告警先核验再删除旧记录再接受新指纹永远优先ssh-keygen -R而不是清空整个 known_hostsRemote-SSH 失败时先看 SSH 握手错误再怀疑编辑器本身。这四条能覆盖日常 80% 以上的「突然连不上」焦虑。十六、复盘时间线可当作案例模板为方便你在团队内做事故复盘给出一个脱敏时间线模板T0编辑器连接dev-box失败耗时约数百毫秒级退出码 255。T01min日志确认REMOTE HOST IDENTIFICATION HAS CHANGED冲突行指向known_hosts某行 ECDSA 记录。T05min打开 known_hosts发现乱码观感误判为文件损坏。T015min二进制检查发现FF FEBOM ASCII 正文的混合形态同时确认目标 IP 存在多条旧主机密钥。T020min确认服务器近期有重装 / 密钥重生通过控制台变更记录或同事同步。T025min备份后删除目标 IP 旧记录重写为 UTF-8 无 BOM。T030min命令行 SSH 核对指纹通过编辑器 Remote-SSH 恢复正常。总耗时若按正确路径可压缩到半小时内若走错误路径可能耗掉半天且引入更多文件损坏。十七、结语乱码是烟雾指纹才是枪声回到文章开头的困惑known_hosts「乱码」让人以为文件坏了日志底部的管道乱码让人以为 Windows 管道坏了真正开枪的是Host key verification failed。SSH 用近乎「不近人情」的方式保护你当远端身份看起来变了它宁可让你连不上也不让你在未确认的情况下把终端、文件、远程开发环境交给可能被调包的机器。作为开发者我们要做的不是关掉这些保护而是读懂告警用带外方式确认精确更新信任缓存保持配置文件编码干净。希望这篇实录能在你下一次遇到红色警告时替你省下那几个小时的无效折腾。如果你有类似案例——比如只有 ED25519 冲突、哈希 known_hosts 删不掉、跳板机二次转发导致指纹错位——欢迎在评论区留下「脱敏后的日志关键行」我们可以继续补一版进阶篇从ProxyJump、SSH CA 到企业级 known_hosts 分发。附录 A命令速查# 删除某主机旧指纹ssh-keygen-R203.0.113.88# 查看远端主机密钥指纹在服务器上执行ssh-keygen-lf/etc/ssh/ssh_host_ed25519_key.pub# 主动扫描并展示指纹需网络可达注意仅作辅助ssh-keyscan-T5203.0.113.88# 测试连接并显示详细握手信息ssh-vvvdeploy203.0.113.88# 备份Copy-Item$env:USERPROFILE\.ssh\known_hosts$env:USERPROFILE\.ssh\known_hosts.bak# 查看文件头两字节检查 BOM$b[System.IO.File]::ReadAllBytes($env:USERPROFILE\.ssh\known_hosts){0:X2} {1:X2}-f$b[0],$b[1]附录 B日志关键词中英文对照原文含义REMOTE HOST IDENTIFICATION HAS CHANGED远程主机身份标识已变更man-in-the-middle attack中间人攻击Offending key本地缓存中冲突的那条密钥strict checking严格主机密钥检查Host key verification failed主机密钥验证失败fingerprint指纹公钥的可读摘要转载声明本文为原创文章如需转载请联系作者获得授权并注明出处。