канал ssh зависает после аутентификации

Question

Рейнджер серверов только вчера перестал отвечать на запросы по ssh, после нескольких месяцев работы, как и ожидалось. Аутентификация проходит успешно, но тогда -vvv logging показывает невероятно длительную задержку, установленную на канале, установленном для сеанса:

debug1: Authentication succeeded (publickey).
Authenticated to ranger ([192.168.1.115]: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 no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
debug3: Ignored env SHELL
debug3: Ignored env TERM
debug3: Ignored env DOCKER_HOST
debug3: Ignored env NVM_DIR
debug3: Ignored env USER
debug3: Ignored env NAME
debug3: Ignored env LS_COLORS
debug3: Ignored env HOSTTYPE
debug3: Ignored env _JAVA_OPTIONS
debug3: Ignored env PATH
debug3: Ignored env PWD
debug3: Ignored env XMODIFIERS
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug3: send packet: type 98
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env LESSOPEN
debug3: Ignored env DISPLAY
debug3: Ignored env LESSCLOSE
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug3: send packet: type 98
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug3: channel_handler: chan 0: skip for 713631 more seconds
debug3: channel_handler: first channel unpauses in 713631 seconds
debug3: channel_handler: chan 0: skip for 713631 more seconds
debug3: channel_handler: first channel unpauses in 713631 seconds
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug3: receive packet: type 99
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
debug3: channel_handler: chan 0: skip for 713631 more seconds
debug3: channel_handler: first channel unpauses in 713631 seconds
debug3: channel_handler: chan 0: skip for 713631 more seconds
debug3: channel_handler: first channel unpauses in 713631 seconds
debug3: channel_handler: chan 0: skip for 713631 more seconds
debug3: channel_handler: first channel unpauses in 713631 seconds

То же самое происходит с другими учетными записями на этом компьютере, в том числе с совершенно новыми, использующими аутентификацию по паролю (возможно, это исключает проблемы .bashrc и т.д.). Аналогично, попытка вызвать совершенно другую команду (ssh -vvv user@ranger 'ls ~') дает то же самое.

Клиент и сервер находятся в одной сети Ethernet, подключенной к одному коммутатору.

Клиент: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 марта 2016 г.

Сервер: Ubuntu 16.04.4, OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 марта 2016 г.

Answer 1

Я тоже на WSL. Исправлено уничтожение всех запущенных экземпляров C:\WINDOWS\System32\bash.exe . До этого открытие новых экземпляров bash не работало.

Я предполагаю, что другие пытались перезагрузить компьютер, но безуспешно, поэтому я не думаю, что это решение широко применимо, но, надеюсь, мои данные помогут кому-то понять, что происходит.

У меня было открыто несколько экземпляров bash, и некоторые из них были открыты в течение нескольких недель, поэтому, возможно, значение общего экспоненциального отката не восстанавливалось. Ранее сегодня значок сети Windows (ложно) сообщал, что у меня нет доступа к сети, так что, возможно, это как-то связано с этим.

Answer 2

Столкнулся с этой идентичной проблемой с WSL openSSH. У любой другой программы ssh не было проблем с входом на локальное устройство. Я попробовал все вышеизложенные предложения безуспешно, даже полностью удалив openSSH-клиент и переустановив.

Затем я попробовал первое, что вы должны делать, когда компьютер ведет себя глупо. Выключите его и включите снова. Все возвращается на круги своя.

Answer 3

Не столько ответ, сколько разрешение: я удалил и переустановил ssh, и все хорошо. ¯ \_(ツ)_/¯