Mám počítač nedávno aktualizovaný na Fedoru 25, na kterém běží openSSH 7.4. Od té doby přihlášení přes ssh trvá 25–30 sekund v síti LAN, kde to normálně netrvá déle než 1 sekundu.
Spuštění klienta s -vvv , pomocí ověřování veřejným klíčem, pauza nastane zde.
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
Vypadá to stejně jako výstup na jiných počítačích (Fedora 23, openSSH 7.2) ve stejné síti, které nemají žádný problém.
Sledování nahoře na straně serveru během přihlašování, systemd krátce vzplane – několik sekund – na začátku pauzy, něco, co není na ostatních strojích patrné. Poté je systém zcela nečinný. Stejně tak nedochází k žádné neobvyklé aktivitě na straně klienta.
Po přihlášení je vše v pořádku.
Sledoval jsem výměnu od klienta s Wireshark a během pauzy se nevyměňují žádné pakety. Klient a server jsou na Ethernetu přes Router, takže jsem také schopen sledovat adresu serveru pro případný provoz. Nic se neděje.
Zde je 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
Podle návrhu Sato Katsury v komentářích jsem to zkusil s UseDNS no; v tom nebyl žádný rozdíl.
Přijatá odpověď:
Ukázalo se, že toto je docela rohový případ.
Stroj je Raspberry Pi, běží na základním jádře Pi, ale s generickým uživatelským prostředím armhf Fedora 25. Byl také nastaven bez hlavy a nikdy se jinak nepoužíval, ale po připojení k monitoru a klávesnici došlo k zjevnému problému s systemd-logind.service . Vystopoval jsem to až k tomuto problému, který byl představen minulý rok, když se základní části systemd staly závislými na seccompu, který z jakéhokoli důvodu není součástí základního jádra Pi, ale možná díky špatné konfiguraci, díky níž se zdá, že ano.
Řešení bylo poměrně jednoduché; možnosti souboru služeb, které vyžadují seccomp, musí být odstraněny. V /usr/lib/systemd/system je jich několik , včetně systemd-logind.service .
Pravděpodobně by to také ve skladovém systému zanechalo deaktivaci sítě, ale k tomu používám svou vlastní službu a ta nebyla ovlivněna (tj. šance, že se s tímto problémem dostane někdo jiný, je mizivá).
Související:Chcete-li, aby byly znaky regulárního výrazu interpretovány jako znaky regulárního výrazu, potřebujete v sed ukončit znaky regulárního výrazu?Každopádně jsem ve všech okomentoval následující řádky:
MemoryDenyWriteExecute=yes
SystemCallFilter=...
Restartováno, žádné další problémy.