☰

Сброс соединенияпорт 22 для всех сайтов

tag-icon • tag-icon networking ssh openssh
Сброс соединенияпорт 22 для всех сайтов

Я использую ПК с Windows 10 с OpenSSH для подключения к облачным виртуальным серверам. Все это время все работало без проблем. Только вчера у меня началась эта странная проблема.
Когда я делаю "ssh support@", он запрашивает у меня пароль, как обычно. Но после того, как я ввожу пароль, он думает около 20 секунд, а затем выдает мне "Сброс соединения по порту 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". На ПК, на котором нет проблем, это гораздо более старая версия "OpenSSH_3.8.1p1, OpenSSK 0.9.7d". Я попытался установить Ubuntu в VirtualBox и надеялся, что ssh в Ubuntu заработает. Но и это не работает. Кажется, на этой машине ничего не работает. Но другой ПК работает нормально. Я нашел похожую проблему в Интернете, и решение — "пересобрать OpenSSH в другом месте". Как это сделать?

решение1

Моя проблема наконец-то решена. Оказывается, виноват был Filezilla. После того, как Filezilla снова обновилась, мой ssh ​​заработал. Я больше никогда не буду обновлять Filezilla. :)
Редактировать: Я поторопился. Теперь мой ssh ​​снова сломался, хотя я ничего не делал, что могло бы на это повлиять. Сначала он просто завис после "channel 0: open verify rwindow 0 rmax 32768". Во многих сообщениях в Интернете упоминалось, что это вызвано проблемой Wi-Fi. Поэтому я отключил свое соединение Wi-Fi и использовал только проводное соединение. Затем он снова сбрасывается пиром.
Это сводит меня с ума. Думаю, я подожду следующего обновления Filezilla и буду надеяться, что это решит мою проблему.
Мое окончательное решение — удалить Filezilla, и мой клиент SSH снова заработал. Затем я установил более старую версию Filezilla (3.41), и она все еще работает.

Связанный контент