☰

連線重置所有站點的連接埠 22

tag-icon • tag-icon networking ssh openssh
連線重置所有站點的連接埠 22

我一直在使用具有 OpenSSH 的 Windows 10 PC 連接到雲端虛擬伺服器。它一直在工作，沒有出現任何問題。就在昨天，我開始遇到這個奇怪的問題。
當我執行“ssh support@”時，它會像往常一樣提示我輸入密碼。但當我輸入密碼後，它會思考大約 20 秒，然後給我「Connection Reset by port 22」。它對我嘗試過的所有網站都執行此操作。
使用另一台電腦（也使用 win10 和 OpenSSH），我可以透過 SSH 連接到我的雲端伺服器。顯然，幾天前這台電腦上發生了一些變化。但我不知道這可能是什麼以及如何解決。我唯一能想到的是我在這台電腦上更新了 FileZilla。會是這樣嗎？
任何幫助將不勝感激。
一些更相關的資訊。我檢查了我的雲端伺服器上的安全性日誌，它顯示我的密碼已被接受並開啟了互動式會話。我在日誌文件中沒有看到任何錯誤。在客戶端，當我嘗試 ssh -vvv 時，我看到一些錯誤，如下所示，

debug1: Next authentication method: password
debug3: failed to open file:/dev/tty error:3
debug1: read_passphrase: can't open /dev/tty: No such file or directory
support@<ip>'s password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to <ip> ([ip]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug1: console supports the ansi parsing
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: recv - from CB ERROR:10060, io:00000206F94181A0
debug3: send packet: type 1
debug3: send - WSASend() ERROR:10054, io:00000206F94181A0
Connection reset by <ip> port 22

我還發現，在連接有問題的電腦上，它顯示“OpenSSH_for_Windows_7.6p1，LibreSSL 2.6.4”。在沒有問題的 PC 上，它是較舊的“OpenSSH_3.8.1p1，OpenSSK 0.9.7d”。我嘗試在 virtualbox 中安裝 ubuntu，並希望 ubuntu 中的 ssh 能夠運作。但它也不起作用。看來這台機器上什麼都不行。但另一台電腦運作正常。我在網路上發現了類似的問題，解決方案是「將 OpenSSH 重建到不同的位置」。我怎樣才能做到這一點？

答案1

我的問題終於解決了。事實證明 Filezilla 是罪魁禍首。 Filezilla 再次更新後，我的 ssh 開始工作。我再也不會更新 Filezilla 了。 :)
編輯：我說太早了。現在我的 ssh 再次損壞，而我沒有做任何我知道可能會影響它的事情。首先，它只是在「通道 0：開啟確認 rwindow 0 rmax 32768」之後掛起。許多網路貼文提到這是由 wifi 問題引起的。所以我關掉了wifi連接，只使用有線連接。然後它再次被peer重置。
這真讓我抓狂。我想我會等待下一次 Filezilla 更新並希望這能解決我的問題。
我的最終解決方案是刪除 Filezilla，然後我的 SSH 客戶端再次開始工作。然後我安裝了舊版的 Filezilla (3.41)，它仍然有效。

相關內容