Ho una macchina recentemente aggiornata a Fedora 25, che esegue openSSH 7.4. Da allora, l'accesso tramite ssh richiede 25-30 secondi su una LAN dove normalmente non ci vuole più di 1 secondo.
Esecuzione del client con -vvv , utilizzando l'autenticazione a chiave pubblica, la pausa si verifica qui.
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
Sembra identico all'output su altre macchine (Fedora 23, openSSH 7.2) sulla stessa rete che non hanno alcun problema.
Guardando dall'alto sul lato server durante l'accesso, systemd si accende brevemente - alcuni secondi - all'inizio della pausa, qualcosa che non si nota sulle altre macchine. Dopodiché il sistema è completamente inattivo. Allo stesso modo, non ci sono attività insolite sul lato client.
Una volta effettuato l'accesso, va tutto bene.
Ho guardato lo scambio dal client con Wireshark e durante la pausa non ci sono pacchetti scambiati. Il client e il server sono su Ethernet tramite un router, quindi sono anche in grado di controllare l'indirizzo del server per qualsiasi traffico. Non sta succedendo niente.
Ecco il 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
Come da suggerimento di Sato Katsura nei commenti, ho provato con UseDNS no; questo non ha fatto alcuna differenza.
Risposta accettata:
Si scopre che questo è proprio un caso d'angolo.
La macchina è un Raspberry Pi, che esegue il kernel Pi di serie, ma con un generico armhf Fedora 25 userland. È stato anche configurato senza testa e non è mai stato utilizzato in altro modo, ma quando è stato collegato a un monitor e una tastiera si è verificato un problema evidente con systemd-logind.service . L'ho ricondotto a questo problema, che è stato introdotto l'anno scorso quando le parti principali di systemd sono diventate dipendenti da seccomp, che per qualsiasi motivo non è incluso nel kernel Pi di serie, ma forse a causa di un'errata configurazione che fa sembrare che lo sia.
La soluzione era abbastanza semplice; le opzioni del file di servizio che richiedono seccomp devono essere rimosse. Ce ne sono una manciata in /usr/lib/systemd/system , incluso systemd-logind.service .
Probabilmente lascerebbe anche la rete disabilitata su un sistema di riserva, ma uso il mio servizio per questo e non è stato influenzato (ad esempio, la possibilità che qualcun altro si imbatta in questo problema in questo modo è scarsa).
Correlati:è necessario sfuggire ai caratteri regex in sed per essere interpretati come caratteri regex?Ad ogni modo, ho commentato le seguenti righe in tutte:
MemoryDenyWriteExecute=yes
SystemCallFilter=...
Riavviato, niente più problemi.