遇到该问题:kex_exchange_identification: read: Connection reset`的解决办法

kex_exchange_identification: read: Connection reset` 是一个非常常见的 SSH 连接错误。它表明在 SSH 客户端和服务器建立安全连接的初始阶段（密钥交换，Key Exchange），连接就被对方（服务器）强制关闭了。

这通常不是客户端的问题，而是服务器端因为某些原因拒绝了你的连接请求。

下面我们来系统地排查和解决这个问题，从最常见到最不常见的原因逐一分析。

1. 服务器端的 SSH 服务没有运行或崩溃

这是最常见的原因。sshd 服务可能没有启动，或者启动后因为某种错误退出了。

解决方案（在被连接的电脑，即 10.49.71.114 的 WSL 中操作）：

1. 检查 SSH 服务状态：

   sudo service ssh status
   # 或者
   sudo systemctl status ssh
   

   • 如果你看到 Active: active (running)，说明服务正在运行。
   • 如果你看到 Active: inactive (dead) 或类似信息，说明服务没有运行。

2. 启动/重启 SSH 服务：

   • 如果服务未运行，启动它：

     sudo service ssh start
     # 或者
     sudo systemctl start ssh
     

   • 如果服务正在运行但你怀疑它有问题，重启它：

     sudo service ssh restart
     # 或者
     sudo systemctl restart ssh
     

3. 设置为开机自启（推荐）：
   为了避免每次重启 WSL 都要手动开启，可以设置服务自启动。但 WSL1 不支持 systemd，WSL2 需要额外配置才能支持。一个简单的替代方法是编辑 ~/.bashrc 或 ~/.zshrc 文件，在末尾加入：

   # 检查 sshd 是否在运行，如果没有则启动
   if ! pgrep -x "sshd" > /dev/null; then
       sudo service ssh start
   fi
   

2. 防火墙问题

Windows 防火墙或者 WSL 内部的防火墙（如 ufw）可能阻止了 2222 端口的连接。

解决方案：

a) Windows 防火墙（最可能的原因）

你需要在作为服务器的 Windows 电脑上（即 10.49.71.114）添加入站规则，允许外部访问 2222 端口。

1. 以管理员身份打开 PowerShell。
2. 执行以下命令，添加一个允许 TCP 流量访问 2222 端口的防火墙规则：

   New-NetFirewallRule -DisplayName "WSL SSH Inbound" -Direction Inbound -Protocol TCP -LocalPort 2222 -Action Allow
   

   这条命令会创建一个名为 “WSL SSH Inbound” 的规则。

b) WSL 内部的防火墙（如果安装了的话）

1. 在 WSL 终端中检查 ufw 状态：

   sudo ufw status
   

2. 如果 ufw 是激活状态 (Status: active)，需要允许 2222 端口：

   sudo ufw allow 2222/tcp
   

3. SSH 配置问题 (/etc/ssh/sshd_config)

服务器端的 SSH 配置文件可能设置了过于严格的连接限制。

解决方案（在 WSL 中操作）：

1. 编辑配置文件：

   sudo nano /etc/ssh/sshd_config
   

2. 检查以下几个关键配置：

   • Port 2222：确保端口号是你正在使用的 2222。
   • ListenAddress 0.0.0.0：确保 SSH 服务监听所有网络接口，这样局域网才能访问。如果它被设置为 127.0.0.1，就只有 WSL 内部能访问。
   • AllowUsers 或 DenyUsers：检查是否有这些行。如果你设置了 AllowUsers，请确保你的用户名 hujh 在列表里。如果没有特殊需求，建议先将这两行注释掉（在行首加 #）。
   • MaxStartups：这个值定义了允许的并发未认证连接数。默认值通常是 10:30:100。如果短时间内有太多失败的连接尝试，可能会触发限制。可以尝试将其改得宽松一些，比如 MaxStartups 30:30:100，但这通常不是主要原因。

3. 修改配置后，必须重启 SSH 服务才能生效：

   sudo service ssh restart
   

4. IP 地址问题

你需要确保你连接的 IP 地址 10.49.71.114 确实是 WSL 所在宿主机 Windows 的局域网 IP。

WSL2 在默认配置下，其网络是 NAT 模式，它有自己的一个虚拟 IP 地址，通常是 172.x.x.x 网段。从局域网的其他电脑直接访问这个虚拟 IP 是不行的。你必须通过宿主机 Windows 的 IP 地址，并设置端口转发。

你已经在 Windows 上监听了 2222 端口，这很可能就是通过端口转发实现的。现在需要确认这个机制是否正确。

解决方案（在作为服务器的 10.49.71.114 电脑上操作）：

1. 获取 WSL 的 IP 地址：在 WSL 终端中运行 ip addr 或 hostname -I，记下这个 IP（例如 172.20.13.14）。
2. 获取 Windows 的局域网 IP 地址：在 Windows 的 CMD 或 PowerShell 中运行 ipconfig，找到连接到局域网的那个网络适配器（通常是“以太网适配器”或“无线局 vực 网适配器”），确认其 IPv4 地址就是 10.49.71.114。
3. 检查/设置端口转发：你需要一个规则，将从 10.49.71.114:2222 进来的流量转发到 [WSL的IP]:22（假设 WSL 里的 SSH 服务运行在默认的 22 端口）。
   • 以管理员身份打开 PowerShell。
   • 运行以下命令来设置端口转发（请将 [WSL的IP] 替换为你在步骤1中找到的真实IP）：

     netsh interface portproxy add v4tov4 listenport=2222 listenaddress=0.0.0.0 connectport=22 connectaddress=[WSL的IP]
     

     例如：netsh interface portproxy add v4tov4 listenport=2222 listenaddress=0.0.0.0 connectport=22 connectaddress=172.20.13.14
   • 重要：每次重启 WSL2，它的 IP 地址可能会改变。这会导致端口转发失效。可以写一个脚本来自动更新这个规则。

排查步骤总结

我建议你按照以下顺序进行排查：

1. 【服务器端 WSL】 确认 SSH 服务状态并重启：sudo service ssh restart。这是最快最简单的尝试。
2. 【服务器端 Windows】 检查并添加防火墙规则，允许 2222 端口入站。
3. 【客户端】 在你的电脑上，用 -vvv 选项运行 SSH 命令，获取更详细的调试信息：

   ssh -vvv [email protected] -p 2222
   

   仔细查看输出，它会告诉你连接断开前最后发生了什么，这对于定位问题非常有帮助。
4. 【服务器端 Windows & WSL】 检查 WSL2 的 IP 地址和 Windows 的端口转发规则是否正确匹配。如果不确定，删除旧规则 (netsh interface portproxy delete ...) 并重新添加。
5. 【服务器端 WSL】 检查 sshd_config 文件是否有过于严格的限制。

通常情况下，问题会出在第1、2、4步中的某一个。