Ich habe in der Vergangenheit schon oft erlebt, dass SSH-Logins mehrere Sekunden dauerten. Das fand ich immer unangemessen. Nachdem ich meine Workstations mit Xubuntu 16.04 neu installiert hatte, wurde dieser Effekt wirklich störend. Zwischen zwei Workstations im selben LAN dauert ein SSH-Login mehr als 10 Sekunden. Danach geht alles wieder schnell.
Die Maschinen können sich über meinen Router in kürzester Zeit über DNS finden. Ich habe jedoch auch versucht UseDNS no. Ich habe auch versucht GSSAPIAuthentication no, was ich im Internet gefunden habe. Beides hatte keine Wirkung.
Ich authentifiziere mich mittels öffentlichem Schlüssel.
Dies ist ein Ausschnitt der Debug-Ausgabe des SSH-Clients:
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/pino/.ssh/ids/heisterkamp/22/pino
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
debug3: sign_and_send_pubkey: RSA XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to heisterkamp ([fd00::8d93:c17b:595a:347f]:22).
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: exec
Nun 'schläft' das Ding für die 10 Sekunden. Danach geht es so weiter:
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug3: receive packet: type 91
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug3: send packet: type 98
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IPV6_TCLASS 0x10
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug3: send packet: type 98
debug1: Sending environment.
...
Sieht jemand den Grund für die Wartezeit?
Bearbeiten: Es gibt noch einige weitere Details, die erwähnenswert sind:
- Wenn ich meine Arbeitsstationen verwende, um mich bei anderen Debian-Maschinen im selben Netzwerk anzumelden, dauert dies nur eine Sekunde.
- Ich habe pam_mount so konfiguriert, dass beim Anmelden ein mit Luks verschlüsseltes Volume gemountet wird. In meinem Fall ist dieses Volume jedoch bereits gemountet. Und das Mounten sollte, selbst wenn es nicht gemountet ist, nur etwa 3 Sekunden dauern.
Antwort1
Gleiches Problem. Beachten Sie, dass ich nach der Verzögerung von 10 Sekunden Folgendes sehen kann: "Dienst „org.freedesktop.login1“ konnte nicht aktiviert werden: Zeitüberschreitung" im auth.log
Lösung:
systemctl restart systemd-logind
Fand esHier
Antwort2
Dies löste in meinem Fall das Problem mit dem Hängenbleiben bei „debug1: pledge: exec“:
apt install --reinstall systemd