Ich habe einen Computer, der kürzlich auf Fedora 25 aktualisiert wurde und auf dem openSSH 7.4 ausgeführt wird. Seitdem dauert die Anmeldung über ssh 25-30 Sekunden in einem LAN, wo es normalerweise nicht länger als 1 Sekunde dauert.
Ausführen des Clients mit -vvv , bei Verwendung der Authentifizierung mit öffentlichem Schlüssel, tritt die Pause hier auf.
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
Dies sieht identisch aus mit der Ausgabe an andere (Fedora 23, openSSH 7.2) Maschinen im selben Netzwerk, die keine Probleme haben.
Oben auf der Serverseite während des Logins aufpassen, systemd flackert zu Beginn der Pause kurz auf – einige Sekunden –, was bei den anderen Maschinen nicht auffällt. Danach ist das System komplett im Leerlauf. Ebenso gibt es keine ungewöhnlichen Aktivitäten auf der Clientseite.
Einmal eingeloggt ist alles in Ordnung.
Ich habe den Austausch vom Client mit Wireshark beobachtet und während der Pause werden keine Pakete ausgetauscht. Der Client und der Server sind über einen Router im Ethernet, sodass ich auch die Serveradresse auf Datenverkehr überwachen kann. Es ist nichts los.
Hier ist die 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
Gemäß dem Vorschlag von Sato Katsura in den Kommentaren habe ich es mit UseDNS no versucht; das machte keinen Unterschied.
Akzeptierte Antwort:
Es stellt sich heraus, dass dies ein ziemlicher Sonderfall ist.
Die Maschine ist ein Raspberry Pi, auf dem der Standard-Pi-Kernel ausgeführt wird, jedoch mit einem generischen armhf Fedora 25-Benutzerland. Es wurde auch kopflos eingerichtet und nie anderweitig verwendet, aber als es an einen Monitor und eine Tastatur angeschlossen war, gab es ein offensichtliches Problem mit systemd-logind.service . Ich habe es auf dieses Problem zurückgeführt, das letztes Jahr eingeführt wurde, als Kernteile von systemd von seccomp abhängig wurden, das aus irgendeinem Grund nicht im Standard-Pi-Kernel enthalten ist, aber möglicherweise durch eine Fehlkonfiguration, die den Anschein erweckt, dass es so ist.
Die Lösung war ziemlich einfach; Servicedateioptionen, die seccomp erfordern, müssen entfernt werden. Es gibt eine Handvoll davon in /usr/lib/systemd/system , einschließlich systemd-logind.service .
Es würde wahrscheinlich auch das Netzwerk auf einem Standardsystem deaktiviert lassen, aber ich verwende meinen eigenen Dienst dafür und das war nicht betroffen (d. h. die Wahrscheinlichkeit, dass jemand anderes auf diese Weise auf dieses Problem stößt, ist gering).
Verwandte:Muss Regex-Zeichen in sed als Regex-Zeichen interpretiert werden?Wie auch immer, ich habe die folgenden Zeilen in allen auskommentiert:
MemoryDenyWriteExecute=yes
SystemCallFilter=...
Neustart, keine Probleme mehr.