kex_exchange_identification: read: connection reset by peer表明服务端在ssh密钥交换阶段主动拒绝连接，常见原因包括sshd未运行、22端口被占用、tcp wrapper拦截（如/etc/hosts.deny生效）、资源耗尽或selinux限制，而非网络或防火墙问题。
ssh -vvv 能立刻定位是客户端还是服务端问题
看到 kex_exchange_identification: read: Connection reset by peer，别急着改配置或重启服务器。先在本地终端执行 ssh -vvv user@host（加三个 v），观察输出最开头几行——如果卡在 debug1: Connecting to host [x.x.x.x] port 22 之后、连 SSH-2.0- 服务端标识都没收到，基本可断定问题出在服务端或网络链路层。
常见现象包括：
- 输出停在
debug1: connect to address x.x.x.x port 22后无响应 → 网络不通或防火墙拦截 - 刚打出
debug1: kex_exchange_identification: Connection closed by remote host就断 → 服务端 SSH 进程拒绝握手，大概率是sshd没起来、崩溃了，或被其他进程占了 22 端口 - 能看到
SSH-2.0-OpenSSH_*字样但很快断开 → 服务端策略干预（如/etc/hosts.deny、TCP Wrapper、SELinux）或资源不足
检查 22 端口是否被占用或 sshd 是否真在运行
很多情况下 VSCode 连不上，不是密钥或配置问题，而是远程服务器的 sshd 根本没在监听 22 端口。尤其当 systemctl restart sshd 报错失败时，90% 是端口冲突。
登录服务器图形界面或通过其他方式（如控制台）执行：
-
sudo ss -tlnp | grep ':22'—— 查看谁在监听 22 端口；若显示pid=1993之类非sshd的进程，说明被占用了 -
sudo systemctl status sshd—— 注意看 Active 状态是否为active (running)；若报failed，直接看journalctl -u sshd -n 50 --no-pager最后几十行日志 -
sudo netstat -tulpn | grep ':22'（旧系统）或sudo lsof -i :22—— 备用端口排查命令
确认被占后，sudo kill -9 1993（替换为实际 PID），再 sudo systemctl start sshd 即可恢复。
/etc/hosts.allow 和 /etc/hosts.deny 的隐性拦截
即使 /etc/hosts.deny 是空的，只要文件存在且没配 sshd: ALL 在 hosts.allow 中，某些发行版（如 CentOS 7+、RHEL）默认启用 TCP Wrapper，会按规则拒绝所有连接——这就是为什么加一句 sshd: ALL 到 /etc/hosts.allow 常常“ miraculously works”。
操作要点：
- 编辑
/etc/hosts.allow，追加一行：sshd: ALL（注意冒号后有空格） - 确保
/etc/hosts.deny中没有sshd:相关条目；若有，注释掉或删掉 - 无需重启
sshd，TCP Wrapper 规则实时生效 - 如需限制 IP，写成
sshd: 192.168.1.0/24, 203.0.113.42更安全
VSCode Remote-SSH 自身缓存和状态干扰
VSCode 的 Remote-SSH 扩展会维护自己的连接状态、临时脚本和日志，有时本地缓存损坏会导致反复报错，即使服务端已修复。
实操建议：
- 关闭 VSCode，删除本地
~/.vscode-server（macOS/Linux）或%USERPROFILE%\.vscode-server（Windows）目录 - 清空 VSCode 的 Remote-SSH 输出面板日志，重试连接时勾选 “Show Log” 查看实时输出
- 禁用所有非必要扩展，尤其是代理类（如 SwitchyOmega、Clash for Windows 的系统代理），它们可能劫持 SSH 的 TCP 流量
- 如果用 WSL，确保不是从 WSL 内部启动 VSCode 连宿主机——这种嵌套 SSH 容易触发握手异常
真正棘手的是：错误可能同时由多个因素叠加导致。比如 22 端口被占 → sshd 启动失败 → TCP Wrapper 默认拒绝 → VSCode 缓存残留旧失败状态。逐层验证比盲目重启更省时间。
