服务器游侠经过几个月的正常运行后,昨天 ssh 登录时突然无响应。身份验证成功,但随后-vvv
日志记录显示为会话建立的通道上设置了令人难以置信的长时间延迟:
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
同样的情况也发生在这台机器上的其他帐户上,包括使用密码验证的全新帐户(因此大概可以排除.bashrc
问题等等)。同样,尝试调用完全不同的命令(ssh -vvv user@ranger 'ls ~'
)也会产生同样的结果。
客户端和服务器位于同一个以太网网络上,连接到同一个交换机。
客户端:OpenSSH_7.2p2 Ubuntu-4ubuntu2.2,OpenSSL 1.0.2g 2016 年 3 月 1 日
服务器:Ubuntu 16.04.4、OpenSSH_7.2p2 Ubuntu-4ubuntu2.2、OpenSSL 1.0.2g 2016 年 3 月 1 日
答案1
我在使用 WSL(适用于 Linux 的 Windows 子系统)时遇到了与上述相同的问题,并且之前提到的解决方案对我没有用。
我最终通过重新启动 WSL 解决了该问题。在管理模式下的 PowerShell 中,只需输入:Restart-Service LxssManager
答案2
我也在西弗吉尼亚海岸。杀死所有正在运行的实例即可C:\WINDOWS\System32\bash.exe
解决问题。在此之前,无法打开新的 bash 实例。
我认为其他人也尝试过重新启动,但是没有成功,所以我不认为这个解决方案具有广泛的适用性,但是希望我的数据点能够帮助某些人弄清楚到底发生了什么。
我打开了几个 bash 实例,其中一些已经打开了数周,所以也许共享的指数退避值没有被重置。今天早些时候,Windows 的网络图标(错误地)报告我没有网络访问权限,所以也许这与它有关。
答案3
使用 WSL openSSH 时遇到了同样的问题。其他所有 ssh 程序都可以毫无问题地登录本地设备。我尝试了上述所有建议,但都没有成功,甚至完全卸载 openSSH-client 并重新安装也没有成功。
然后我尝试了当计算机出现故障时应该做的第一件事。关闭它然后再打开。一切都恢复正常了。
答案4
我遇到过几次这个问题。受到 Marc Ho 的启发评论,我退出了所有 WLS 会话,它立即在我打开的下一个会话中运行。不过,我不需要从 .ssh 中删除文件。
我怀疑在睡眠和/或网络更改之间有一个孤立锁。我的 Windows 中恰好有一个网络驱动器作为主驱动器,这可能是导致问题的原因。