☰

SSH 7.4 在“承诺：网络”处长时间暂停

tag-icon • tag-icon ssh fedora systemd raspberry-pi sshd
SSH 7.4 在“承诺：网络”处长时间暂停

我有一台机器最近更新到 Fedora 25，运行 openSSH 7.4。从此以后就通过ssh登录了需要 25-30 秒在 LAN 上，通常不超过 1 秒。

使用 运行客户端-vvv，使用公钥身份验证，此处发生暂停。

debug1: Authentication succeeded (publickey).
Authenticated to crystalline.kodiak ([192.168.0.22]:127).
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

这看起来与同一网络上其他机器（Fedora 23、openSSH 7.2）的输出相同，没有任何问题。

在登录期间在服务器端观看顶部，systemd在暂停开始时短暂地爆发（几秒钟），这在其他计算机上不明显。此后系统完全空闲。同样，客户端也没有异常活动。

登录后一切都很好。

我观察了客户端与 Wireshark 的交换，在暂停期间没有交换数据包。客户端和服务器通过路由器位于以太网上，因此我还可以查看服务器地址的任何流量。什么事也没有发生。

这是sshd_config：

Port 127
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
IgnoreRhosts yes
SyslogFacility AUTHPRIV
LogLevel INFO
TCPKeepAlive yes
ClientAliveInterval 120
ClientAliveCountMax 15
PermitRootLogin yes
StrictModes yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM yes
X11Forwarding no
UsePrivilegeSeparation sandbox
AcceptEnv LANG LC_*
Subsystem   sftp    /usr/libexec/openssh/sftp-server

根据 Sato Katsura 在评论中的建议，我尝试过UseDNS no；这没有任何区别。

答案1

事实证明，这是一个极端的情况。

该机器是 Raspberry Pi，运行普通 Pi 内核，但具有通用的 armhf Fedora 25 用户区。它也被设置为无头并且从未以其他方式使用过，但是当插入显示器和键盘时，存在明显的问题systemd-logind.service。我追踪到这个问题，去年当 systemd 的核心部分变得依赖于安全计算，无论出于何种原因，它都没有包含在现有的 Pi 内核中，但可能是通过错误配置使其看起来如此。

解决方案相当简单；需要删除需要 seccomp 的服务文件选项。中有一些这样的内容/usr/lib/systemd/system，包括systemd-logind.service.

它还可能会在库存系统上禁用网络，但我为此使用自己的服务并且没有受到影响（即，其他人以这种方式遇到此问题的机会很小）。

无论如何，我注释掉了所有这些行中的以下几行：

MemoryDenyWriteExecute=yes
SystemCallFilter=...

重新启动，就没有问题了。

答案2

就我而言，原因是崩溃了rsyslogd。我发现这一点是因为/var/log/secure.

所以我重新启动了服务rsyslog。这为我们解决了问题。

答案3

就我而言，我在服务器上禁用了 DNSsshd_config

UseDNS no

答案4

ESXi就我而言，该问题是由于长时间断电而重新启动时主机负载过大造成的。

在电源恢复时，托管多个（> 30）LXC 容器的 Ubuntu 虚拟机启动，并且所有容器同时启动，大多数容器由于启动负载过大而处于不良状态。为了解决该问题并让开发人员恢复工作，我编写了重新启动所有容器的脚本，每次重新启动之间间隔 30 秒。

当我有时间和一段安静的时间时，我会看看是否能查出真相。我有似曾相识的感觉，我之前已经通过重新启动解决了这个问题logind，还有一个忘记了的服务。

相关内容