Não é uma resposta, tanto quanto uma resolução: eu removi e reinstalei o ssh e tudo está bem. ¯ \ _ (ツ) _ / ¯
O servidor ranger acaba de deixar de responder ao login do ssh, após meses de trabalho como esperado. A autenticação é bem-sucedida, mas, em seguida, -vvv logging revela um incrivelmente longo atraso sendo definido no canal estabelecido para a sessão:
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 [email protected]
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype [email protected] 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
O mesmo ocorre em outras contas nesta máquina, incluindo as completamente novas usando a autenticação por senha (presumivelmente, isso exclui .bashrc problemas e assim por diante). Da mesma forma, tentar invocar um comando completamente diferente ( ssh -vvv user@ranger 'ls ~' ) produz o mesmo.
O cliente e o servidor estão na mesma rede ethernet, conectados ao mesmo switch.
Cliente: OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 de março de 2016
Servidor: Ubuntu 16.04.4, OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 de março de 2016
Não é uma resposta, tanto quanto uma resolução: eu removi e reinstalei o ssh e tudo está bem. ¯ \ _ (ツ) _ / ¯
Correu para este problema idêntico ao WSSS openSSH. Todos os outros programas ssh não tiveram problemas para fazer o login no dispositivo local. Eu tentei todas as sugestões acima, sem sucesso, mesmo desinstalar completamente o openSSH-client e reinstalar.
Então eu tentei a primeira coisa que você deveria fazer quando um computador está agindo de forma estúpida. Desligue e ligue novamente. Tudo voltou ao normal.
Eu também estou no WSL . Matar todas as instâncias em execução de C:\WINDOWS\System32\bash.exe corrigiu. Antes disso, a abertura de novas instâncias bash não funcionava.
Suponho que outros usuários tenham tentado reinicializar, sem sucesso, então não acho que essa solução seja amplamente aplicável, mas espero que meu ponto de dados ajude alguém a descobrir o que está acontecendo.
Eu tinha várias instâncias do bash abertas, e algumas delas estavam abertas há semanas, então talvez um valor de backoff exponencial compartilhado não estivesse sendo redefinido. Hoje, o ícone da rede do Windows estava (falsamente) informando que eu não tinha acesso à rede, então talvez isso tenha algo a ver com isso.