☰

SSH 7.4 "Promise: Network"에서 긴 일시 중지

tag-icon • tag-icon ssh fedora systemd raspberry-pi sshd
SSH 7.4 "Promise: Network"에서 긴 일시 중지

최근 openSSH 7.4를 실행하는 Fedora 25로 업데이트된 시스템이 있습니다. 이제부터는 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

알고 보니 이는 극단적인 경우이다.

이 머신은 기본 Pi 커널을 실행하지만 일반 armhf Fedora 25 사용자 영역이 있는 Raspberry Pi입니다. 또한 헤드리스로 설정되어 있으며 다른 방법으로는 사용한 적이 없지만 모니터와 키보드를 연결할 때 명백한 문제가 있습니다 systemd-logind.service. 나는 추적했다이 문제, 작년에 systemd의 핵심 부분이보안 컴퓨팅, 어떤 이유로든 기존 Pi 코어에 포함되지 않지만 그렇게 표시되도록 구성이 잘못되어 발생할 수 있습니다.

해결 방법은 매우 간단합니다. seccomp가 필요한 서비스 파일 옵션을 제거해야 합니다. /usr/lib/systemd/system를 포함하여 이들 중 일부가 있습니다 systemd-logind.service.

또한 기본 시스템에서 네트워킹을 비활성화할 수도 있지만 저는 이를 위해 내 서비스를 사용하고 있으며 영향을 받지 않았습니다(즉, 다른 사람이 이런 식으로 이 문제를 겪을 가능성은 희박합니다).

어쨌든 나는 그 모든 내용에서 다음 줄을 주석 처리했습니다.

MemoryDenyWriteExecute=yes
SystemCallFilter=...

다시 시작하면 문제가 없습니다.

답변2

제 경우에는 충돌이 원인이었습니다 rsyslogd. 나는 이것을 발견했습니다 /var/log/secure.

그래서 서비스를 다시 시작했습니다 rsyslog. 이것은 우리의 문제를 해결했습니다.

답변3

제 경우에는 서버에서 DNS를 비활성화했습니다.sshd_config

UseDNS no

답변4

ESXi제 경우에는 오랜 정전 후 재시작 시 호스트에 과도한 부하가 걸려서 문제가 발생했습니다.

전원이 복원되면 여러(>30) LXC 컨테이너를 호스팅하는 Ubuntu VM이 시작되고 모든 컨테이너가 동시에 시작됩니다. 시작 로드가 너무 많아 대부분의 컨테이너가 잘못된 상태입니다. 문제를 해결하고 개발자가 다시 작업할 수 있도록 하기 위해 모든 컨테이너를 30초 간격으로 다시 시작하는 스크립트를 작성했습니다.

시간이 좀 있고 조용한 시간이 있을 때 진실을 알아낼 수 있는지 알아보겠습니다. 데자뷰 현상이 발생했습니다. 이전에 재부팅 logind하고 잊어버린 서비스를 사용하여 이 문제를 해결했습니다 .

관련 정보