ssh 连接问题:有时成功/有时超时/有时挂起

ssh 连接问题:有时成功/有时超时/有时挂起

我在 ssh 连接方面遇到了问题。我正在使用我的 Ubuntu 16.04 客户端连接到 Centos7 服务器。我使用 ssh 密钥对建立连接。但随后发生了许多奇怪的事情:有时我可以毫无问题地连接到服务器,有时它会抛出超时错误。有时在服务器上它只是不响应键盘输入。起初我以为这与服务器有关。但使用 putty 在 Windows 10 上测试了连接。它没有任何问题。我也在 AWS 服务器上遇到了这个问题。所以我认为这与我的 Ubuntu 客户端有关。因为从 PuTTY 开始一切都很顺利。

另外:我尝试了几次服务器,但都没有成功。但是从 top 命令(使用 Windows Server)中,我看到了挂起的连接。

在此处输入图片描述

我的连接设置取自 /etc/ssh/ssh_config 和 ~/.ssh/config (我删除了带有 # 注释的部分)

Host *
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no
    KeepAlive yes
    TCPKeepAlive yes
    ServerAliveInterval 60
    ServerAliveCountMax 5
    GSSAPIAuthentication no

这是一次不成功的连接尝试

debug1: Authentication succeeded (publickey).
Authenticated to 91.92.128.50 ([91.92.128.50]: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
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: send packet: type 80
debug3: send packet: type 80
debug3: send packet: type 80
debug3: send packet: type 80
debug3: send packet: type 80
Timeout, server 91.92.128.50 not responding.

有时当我的会话挂起并且我在服务器上时,我会在终端中收到这些通知。(我使用 -vvv 选项连接)

[aeliv@v20920 ~]$ debug3: send packet: type 80
debug3: receive packet: type 82

[aeliv@v20920 ~]$ 
[aeliv@v20920 ~]$ debug3: send packet: type 80
debug3: receive packet: type 82
debug3: send packet: type 80
debug3: send packet: type 80

答案1

如果成功,所有功劳都归功于@Strahinja Kustudic,你可以去https://serverfault.com/a/794789/569013了解更多详情。简而言之,您可以尝试systemctl restart systemd-logind解决该问题。

相关内容