VSCode连接服务器提示“kex_exchange_identification” 修复【方案】

kex_exchange_identification: read: Connection reset by peer表明服务端在SSH密钥交换阶段主动拒绝连接，常见原因包括sshd未运行、22端口被占用、TCP Wrapper拦截（如/etc/hosts.deny生效）、资源耗尽或SELinux限制，而非网络或防火墙问题。 ssh -vvv 能立刻定位是客户端还是服务端问题 看到 ，别急着改配置或重启服务器。先在本地终端执行 （加三个 ），观察输出最开头几行——如果卡在 之后、连 服务端标识都没收到，基本可断定问题出在服务端或网络链路层。 常见现象包括： 输出停在 后无响应 → 网络不通或防火墙拦截 刚打出 就断 → 服务端 SSH 进程拒绝握手，大概率是 没起来、崩溃了，或被其他进程占了 22 端口 能看到 字样但很快断开 → 服务端策略干预（如 、TCP Wrapper、SELinux）或资源不足 检查 22 端口是否被占用或 sshd 是否真在运行 很多情况下 VSCode 连不上，不是密钥或配置问题，而是远程服务器的 根本没在监听 22 端口。尤其当 报错失败时，90% 是端口冲突。 登录服务器图形界面或通过其他方式（如控制台）执行： —— 查看谁在监听 22 端口；若显示 之类非 的进程，说明被占用了 —— 注意看 Active 状态是否为 ；若报 ，直接看 最后几十行日志 （旧系统）或 —— 备用端口排查命令 确认被占后， （替换为实际 PID），再 即可恢复。 /etc/hosts.allow 和 /etc/hosts.deny 的隐性拦截 即使 是空的，只要文件存在且没配 在 中，某些发行版（如 CentOS 7+、RHEL）默认启用 TCP Wrapper，会按规则拒绝所有连接——这就是为什么加一句 到 常常“ miraculously works”。 VSCode 1.118 微软正式发布 Visual Studio Code 1.118 版本 。本次更新重点强化了 AI 开发体验与企业管理能力，其中最引人注目的是新增 Copilot CLI 远程控制功能，允许开发者通过手机或网页远程监控和接管 AI 会话 。同时，为了提高 AI 的运行性价比，新版本优化了令牌缓存策略以降低成本 。此外，1.118 版还引入了 Chronicle 本地历史追踪、TypeScript 7.0 支持以及更严格的企业级访问管控 。 下载 操作要点： 编辑 ，追加一行： （注意冒号后有空格） 确保 中没有 相关条目；若有，注释掉或删掉 无需重启 ，TCP Wrapper 规则实时生效 如需限制 IP，写成 更安全 VSCode Remote-SSH 自身缓存和状态干扰 VSCode 的 Remote-SSH 扩展会维护自己的连接状态、临时脚本和日志，有时本地缓存损坏会导致反复报错，即使服务端已修复。 实操建议： 关闭 VSCode，删除本地 （macOS/Linux）或 （Windows）目录 清空 VSCode 的 Remote-SSH 输出面板日志，重试连接时勾选 “Show Log” 查看实时输出 禁用所有非必要扩展，尤其是代理类（如 SwitchyOmega、Clash for Windows 的系统代理），它们可能劫持 SSH 的 TCP 流量 如果用 WSL，确保不是从 WSL 内部启动 VSCode 连宿主机——这种嵌套 SSH 容易触发握手异常 真正棘手的是：错误可能同时由多个因素叠加导致。比如 22 端口被占 → sshd 启动失败 → TCP Wrapper 默认拒绝 → VSCode 缓存残留旧失败状态。逐层验证比盲目重启更省时间。