Frage SSH-Verbindung dauert ewig zu initiieren, steckte bei "Versprechen: Netzwerk"


Die Verbindung zu einem meiner Server mit ssh dauert mehr als 20 Sekunden.

Dies hängt nicht mit LAN- oder WAN-Bedingungen zusammen, da die Verbindung zu sich selbst dasselbe ist (ssh localhost). Nachdem die Verbindung endlich hergestellt ist, ist es sehr schnell mit dem Server zu interagieren.

Die Verwendung von -vvv zeigt, dass die Verbindung blockiert ist, nachdem "pledge: network" gesagt wurde. An dieser Stelle ist die Authentifizierung (hier unter Verwendung des Schlüssels) bereits durchgeführt, wie hier zu sehen ist:

...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network

(... steckte hier für 15 bis 25 Sekunden ...)

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

Server ist Ubuntu 16.04. Mir ist es schon früher mit einem anderen Server passiert (; war Ubuntu 12.04), nerver fand die Lösung und das Problem verschwand nach einer Weile ...

sshd_config ist das Standardprogramm von Ubuntu.

Bisher habe ich es versucht:

  • Verwenden von -o GSSAPIAuthentication = no im Befehl ssh
  • Verwenden eines Passwortes anstelle eines Schlüssels
  • Verwenden von UsePrivilegeSeparation no anstelle von yes in sshd_config

34
2017-07-28 14:02


Ursprung


In der Regel sind langsame SSH-Verbindungen für mich DNS-Probleme, könnte das hier der Fall sein? Zum Beispiel könnte der Server festgefahren sein, wenn er versucht, einen Reverse-DNS für die IP des Clients auszuführen und darauf zu warten, dass die Zeit überschritten wird - Eric Renouf
Eigentlich nein: Standardmäßig ist UseDNS nicht in sshd_config definiert und die man-Seite sagt, dass diese Option standardmäßig "nein" ist. - M-Jack
Einige Googling schlägt vor, dies kann durch Aktualisieren von Systemd ohne Neustart verursacht werden. Und da war ein Systemd Update für Xenial am 12. Juli. systemctl restart systemd-logind behebt das Problem nur für eine kurze Zeit für mich. - Ivan Kozik
Oder wenn du es siehst pam_systemd(sshd:session): Failed to create session: Connection timed out Wie in einer Antwort erwähnt, könnte dies sein github.com/systemd/systemd/issues/2925 - Ivan Kozik
Ich kam hierher, nachdem dieses Problem nach einem Update hatte, und @ IvanKozik Vorschlag das Problem behoben - d. H. Systemctl restart systemd-logind - also danke dafür. - Paul M


Antworten:


Dies ist wahrscheinlich ein Problem mit D-Bus und systemd. Wenn die dbus Dienst wird aus irgendeinem Grund neu gestartet, Sie müssen auch neu starten systemd-logind.

Sie können überprüfen, ob dies das Problem ist, indem Sie das SSH-Daemon-Protokoll öffnen (auf Ubuntu sollte es sein) /var/log/auth.log) und prüfen Sie, ob es diese Zeilen hat:

sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out

Wenn ja, starte einfach neu systemd-logind Bedienung:

systemctl restart systemd-logind

Ich hatte das gleiche Problem auf CentOS 7, weil die messagebus wurde neu gestartet (so wie der D-Bus Service wird auf CentOS aufgerufen).


37
2017-08-04 08:38



Ich habe versucht, Systemd-Logind neu zu starten, aber nach einer Weile sagt es PolicyKit-Daemon vom Bus getrennt. Wir sind kein registrierter Authentifizierungsagent mehr. Job für systemd-logind.service ist fehlgeschlagen, weil ein Timeout überschritten wurde. Siehe "systemctl status systemd-logind.service" und "journalctl -xe" für Details. - Kun Ren
@KunRen müssen Sie wahrscheinlich neu starten polkit Service mit systemctl restart polkit. - Strahinja Kustudic
Das hat für mich funktioniert, danke :) - Wolfe


fand die Antwort:

UsePAM in der sshd_config-Datei von "yes" auf "no" geändert

Nach dem Neustart des SSH-Dienstes wird die Verbindung sofort zum Server hergestellt. Auf diesem Server ist PAM mit ldap verknüpft, das ist wahrscheinlich der Grund, auch wenn ich hier mit einem Benutzer verbunden bin, der auf dem Server selbst deklariert ist, nicht ein LDAP-Server.

Nun, das ist mehr eine Möglichkeit, das Problem zu umgehen, nicht wirklich eine Lösung ... Ich habe andere Server eingerichtet, die dieses Problem nicht haben.

Hoffe das kann jemandem helfen ...


12
2017-07-28 14:14



Ändern UsePAM zu Nein hat andere Effekte. Sehen diese Diskussion  Also musste ich ein Passwort für den Benutzer setzen, da ich Fehler wie User nagios nicht bekommen konnte, weil das Konto gesperrt ist - M-Jack
Das ist wirklich keine gute Idee. - Jakuje
Warum ?? irgendeine Alternative? - M-Jack
Das PAM wird für andere Dinge rund um die Kontoverwaltung in modernen Systemen verwendet. Anstatt es auszuschalten, sollten Sie lieber untersuchen, was im PAM-Stack vor sich geht und warum es so lange dauert. - Jakuje
Verlassen sehr häufig unbenutzten PAM-Modul aktiviert Für SSH-Zugriff ist eine Sicherheitslücke. Die Beschränkung des Zugriffs auf kritische Dienste wie SSH aus Sicherheitsgründen ist auch für JEDEN anderen Dienst eine gute Idee. Wann möchten Sie, dass das PAM-Modul mit SSH zusammenarbeitet? Zum Beispiel: Wenn Sie es mit Active Directory über Winbind integrieren müssen, wenn Sie zwei Faktorauth mit Google-Token, etc. benötigen. In anderen Fällen (wenn passwd und shadow verwendet werden) ist es absolut sicher. Jeder Benutzer von PAM soll dies sehen: cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pam - Michal Sokolowski


Dies geschah auf zwei meiner Fedora 25-Servern und war auf viele fehlgeschlagene SSH-Anmeldeversuche zurückzuführen.

(Die üblichen Vorschläge zur Verwendung GSSAPIAuthentication=no und UseDNS=nooder neu starten systemd-logind, machte keinen Unterschied.)

Auf diesen Servern /etc/pam.d/postlogin enthält:

session     optional      pam_lastlog.so silent noupdate showfailed

Die Manpage für pam_lastlog erklärt, dass die showfailed Option wird:

Zeigt die Anzahl fehlgeschlagener Anmeldeversuche und das Datum des letzten fehlgeschlagenen Versuchs von btmp an.

Auf diesen Servern ist der /var/log/btmp Die Dateien waren aufgrund vieler fehlgeschlagener Anmeldeversuche enorm. Das btmp Protokolldateien wurden auch nicht gedreht.

Ich habe das installiert logrotate Paket, um sicherzustellen, dass die Protokolldateien in Zukunft rotiert werden. (Auf Fedora wurde die Konfiguration mit ausgeliefert logrotate selbst behandelt die Rotation von /var/log/btmp.)

Ich habe auch das enorme gelöscht btmp Protokolldateien; Sobald ich dies getan hatte, war die Verbindung zu den Servern sofort wieder hergestellt.


6
2018-06-10 23:23



Das hat mein Problem gelöst! Vielen Dank. Netter Fang. SSH brauchte 5-10 Sekunden, und jetzt ist es weniger als ein Wimpernschlag. Dies ist auf einer VM, die ich seit Jahren mit dem öffentlichen Internet verbunden habe. Seine Firewall-Regeln könnten wahrscheinlich etwas besser abgestimmt werden, wenn ich daran denke. Für andere ist das alles, was ich getan habe: sudo truncate -s 0 /var/log/btmp- Meine war 2,7G groß. - Carl Bennett


In meinem Fall war der Grund ein abgestürztes rsyslogd. Ich fand das heraus, weil es keine Log-Nachrichten mehr in z.B. / var / log / syslog oder /var/log/mail.log

So service rsyslog restart hat das Problem für uns gelöst.


1
2018-06-29 07:44



Gleiche Ursache auf einem unserer Server unter CentOS 6.10. Neustart von rsyslog hat dafür gesorgt. Die Sache ist, es war nicht tot. Es lief, aber scheinbar nutzlos. - UtahJarhead


Für mich wird dieses Problem durch große (Hunderte von MBs) verursacht btmp Datei. Diese Datei protokolliert Anmeldeversuche. Wenn Leute versuchen, Ihr Passwort brutal zu erzwingen, kann diese Datei sehr groß sein und Verzögerungen verursachen "pledge: network" Phase.

Versuchen Sie, die Protokolldatei zu löschen

echo "" > /var/log/btmp

und sehen, ob es hilft.


0
2018-06-15 10:38



Das braucht viel mehr Erklärung. Für Anfänger, warum ist das Ihrer Meinung nach hilfreich? - Sven♦


Ich habe die folgende Zeile in meinem Debug-Feedback bemerkt:

Control socket connect(/var/lib/jenkins/.ssh/USER@HOST:22): Permission denied

Welches war eine Datei, die im Besitz von war root:root während ich bin jenkins. Durch das Entfernen dieser Datei wurden meine Probleme behoben.


0
2018-01-11 21:35