it-swarm.com.de

Die Initiierung einer SSH-Verbindung dauert ewig. Sie bleibt bei "pledge: network" hängen.

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

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

Die Verwendung von -vvv zeigt, dass die Verbindung nach dem Versprechen "Versprechen: Netzwerk" hängen bleibt. Zu diesem Zeitpunkt ist die Authentifizierung (hier mit Schlüssel) bereits abgeschlossen, wie hier sichtbar:

...
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 [email protected]
debug1: Entering interactive session.
debug1: pledge: network

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

debug1: client_input_global_request: rtype [email protected] want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

Server ist Ubuntu 16.04. Es ist mir schon in der Vergangenheit mit einem anderen Server passiert (war Ubuntu 12.04), nerver hat die Lösung gefunden und das Problem ist nach einer Weile verschwunden ...

sshd_config ist die von Ubuntu bereitgestellte Standardeinstellung.

Bisher habe ich versucht:

  • verwenden von -o GSSAPIAuthentication = no im Befehl ssh
  • verwenden Sie ein Passwort anstelle eines Schlüssels
  • verwenden von UsePrivilegeSeparation no anstelle von yes in sshd_config
50
M-Jack

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

Sie können überprüfen, ob dies das Problem ist, indem Sie das ssh-Daemon-Protokoll öffnen (unter Ubuntu sollte es /var/log/auth.log Sein) und prüfen, ob es folgende Zeilen enthält:

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

Wenn ja, starten Sie einfach den systemd-logind - Dienst neu:

systemctl restart systemd-logind

Ich hatte das gleiche Problem unter CentOS 7, weil messagebus neu gestartet wurde (so wird der Dienst D-Bus Unter CentOS aufgerufen).

43

fand die Antwort:

usePAM wurde in der Datei sshd_config von yes in no geändert

Nach dem Neustart des SSH-Dienstes wird jetzt sofort eine Verbindung zum Server hergestellt. Auf diesem Server ist PAM mit ldap verknüpft, daher ist dies wahrscheinlich der Grund, auch wenn ich hier eine Verbindung mit einem auf dem Server selbst deklarierten Benutzer herstelle, nicht mit einem LDAP-Benutzer.

Nun, dies ist eher eine Möglichkeit, das Problem zu umgehen, nicht wirklich eine Lösung ... Ich habe andere Server auf die gleiche Weise eingerichtet, auf denen dieses Problem nicht auftritt.

Hoffe das kann jemandem helfen ...

19
M-Jack

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

(Die allgemeinen Vorschläge zur Verwendung von GSSAPIAuthentication=no und UseDNS=no oder Neustart 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 Option showfailed:

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

Auf diesen Servern wird /var/log/btmp Dateien waren aufgrund vieler fehlgeschlagener Anmeldeversuche enorm. Die btmp -Protokolldateien wurden ebenfalls nicht gedreht.

Ich habe das Paket logrotate installiert, um sicherzustellen, dass die Protokolldateien in Zukunft gedreht werden. (Unter Fedora übernimmt die mit logrotate gelieferte Konfiguration die Rotation von /var/log/btmp.)

Ich habe auch die riesigen btmp Protokolldateien gelöscht; Sobald ich dies tat, war die Verbindung zu den Servern sofort wieder hergestellt.

11
Richard Fearn

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

Versuchen Sie, die Protokolldatei zu löschen

echo "" > /var/log/btmp

und sehen, ob es hilft.

2
Marek Nagy

In meinem Fall war der Grund ein abgestürzter rsyslogd. Ich fand dies heraus, weil es keine Protokollnachrichten mehr in z./var/log/syslog oder /var/log/mail.log

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

2
randomcontrol

Für mich war die Lösung das Hinzufügen

UseDNS no

zum /etc/ssh/sshd_config und dann natürlich service ssh restart (auf unserem Debian/Jessie-Server). Nichts anderes...

vorher:

ssh [email protected]*****.de true  0.03s user 0.01s system 0% cpu 13.440 total
ssh [email protected]*****.de true  0.03s user 0.01s system 0% cpu 20.990 total
ssh [email protected]*****.de true  0.03s user 0.02s system 0% cpu 31.114 total
ssh [email protected]*****.de true  0.03s user 0.01s system 0% cpu 25.898 total

nach:

ssh [email protected]*****.de true  0.03s user 0.02s system 5% cpu 0.832 total
ssh [email protected]*****.de true  0.03s user 0.01s system 7% cpu 0.523 total
ssh [email protected]*****.de true  0.03s user 0.01s system 7% cpu 0.574 total
1
tamasgal

Unter Ubuntu 16+ jedes Mal, wenn ich ssh -v [email protected] Abwürgen bei pledge: network es kann behoben werden, indem man den Anweisungen folgt, die ich hier gefunden habe Eine umfassende Anleitung zum Beheben langsamer SSH-Anmeldungen . Insbesondere ein optionales PAM-Modul, das nicht benötigt zu werden scheint, verursacht die Verzögerung.

Im /etc/pam.d/common-session auf dem Computer sehen Sie langsame Anmeldungen für (dh den Server). Kommentiere die Zeile aus session optional pam_systemd.so. Das sollte das Problem sofort beheben.

Dadurch wird vermieden, dass PAM vollständig heruntergefahren werden muss, wodurch die Anmeldung mit Kennwörtern beeinträchtigt wird.

1
Jonathan Gutow

In meinem Debug-Feedback ist mir folgende Zeile aufgefallen:

Control socket connect(/var/lib/jenkins/.ssh/[email protected]:22): Permission denied

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

0
Ambidex

Das Problem für mich (Ubuntu 19.10) war, dass mein:

/etc/pam.d/sshd

# Print the message of the day upon successful login.
# This includes a dynamically generated part from /run/motd.dynamic
# and a static (admin-editable) part from /etc/motd.
session    optional     pam_motd.so  motd=/run/motd.dynamic
session    optional     pam_motd.so noupdate

Das Kommentieren der Motd-Einstellungen hat mich richtig reingelegt.

0
Walter