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; thensudo 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 hujh@10.49.71.114 -p 2222
   

   仔細查看輸出，它會告訴你連接斷開前最后發生了什么，這對于定位問題非常有幫助。
4. 【服務器端 Windows & WSL】 檢查 WSL2 的 IP 地址和 Windows 的端口轉發規則是否正確匹配。如果不確定，刪除舊規則 (netsh interface portproxy delete ...) 并重新添加。
5. 【服務器端 WSL】 檢查 sshd_config 文件是否有過于嚴格的限制。

通常情況下，問題會出在第1、2、4步中的某一個。