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

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

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

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

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

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

检查 SSH 服务状态：
bash 复制代码
```
sudo service ssh status
# 或者
sudo systemctl status ssh
```
- 如果你看到 Active: active (running)，说明服务正在运行。
- 如果你看到 Active: inactive (dead) 或类似信息，说明服务没有运行。
启动/重启 SSH 服务：
- 如果服务未运行，启动它：
  bash 复制代码
```
sudo service ssh start
# 或者
sudo systemctl start ssh
```
- 如果服务正在运行但你怀疑它有问题，重启它：
  bash 复制代码
```
sudo service ssh restart
# 或者
sudo systemctl restart ssh
```
设置为开机自启（推荐） ：

为了避免每次重启 WSL 都要手动开启，可以设置服务自启动。但 WSL1 不支持 systemd，WSL2 需要额外配置才能支持。一个简单的替代方法是编辑 ~/.bashrc 或 ~/.zshrc 文件，在末尾加入：
bash 复制代码
```
# 检查 sshd 是否在运行，如果没有则启动
if ! pgrep -x "sshd" > /dev/null; then
    sudo service ssh start
fi
```

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

解决方案：

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

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

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

在 WSL 终端中检查 ufw 状态：
bash 复制代码
```
sudo ufw status
```
如果 ufw 是激活状态 (Status: active)，需要允许 2222 端口：
bash 复制代码
```
sudo ufw allow 2222/tcp
```

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

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

编辑配置文件：
bash 复制代码
```
sudo nano /etc/ssh/sshd_config
```
检查以下几个关键配置：
- 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，但这通常不是主要原因。
修改配置后，必须重启 SSH 服务才能生效：
bash 复制代码
```
sudo service ssh restart
```

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

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

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

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

获取 WSL 的 IP 地址 ：在 WSL 终端中运行 ip addr 或 hostname -I，记下这个 IP（例如 172.20.13.14）。
获取 Windows 的局域网 IP 地址 ：在 Windows 的 CMD 或 PowerShell 中运行 ipconfig，找到连接到局域网的那个网络适配器（通常是"以太网适配器"或"无线局 vực 网适配器"），确认其 IPv4 地址就是 10.49.71.114。
检查/设置端口转发 ：你需要一个规则，将从 10.49.71.114:2222 进来的流量转发到 [WSL的IP]:22（假设 WSL 里的 SSH 服务运行在默认的 22 端口）。
- 以管理员身份打开 PowerShell。
- 运行以下命令来设置端口转发（请将 [WSL的IP] 替换为你在步骤1中找到的真实IP）：
  powershell 复制代码
```
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 地址可能会改变。这会导致端口转发失效。可以写一个脚本来自动更新这个规则。

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

【服务器端 WSL】 确认 SSH 服务状态并重启：sudo service ssh restart。这是最快最简单的尝试。
【服务器端 Windows】 检查并添加防火墙规则，允许 2222 端口入站。
【客户端】 在你的电脑上，用 -vvv 选项运行 SSH 命令，获取更详细的调试信息：
bash 复制代码
```
ssh -vvv hujh@10.49.71.114 -p 2222
```
仔细查看输出，它会告诉你连接断开前最后发生了什么，这对于定位问题非常有帮助。
【服务器端 Windows & WSL】 检查 WSL2 的 IP 地址和 Windows 的端口转发规则是否正确匹配。如果不确定，删除旧规则 (netsh interface portproxy delete ...) 并重新添加。
【服务器端 WSL】 检查 sshd_config 文件是否有过于严格的限制。

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