Warum ist meine SSH-Verbindung langsam? Fünf sofortige Lösungen für Latenzprobleme

Langsames SSH ist nicht ein Problem. Manchmal tritt die Verzögerung auf, bevor Sie überhaupt eine Eingabeaufforderung erhalten. Manchmal ist der Login schnell, aber jeder Tastendruck fühlt sich klebrig an. Manchmal wird SSH für ein langsames Shell-Startskript, eine blockierte DNS-Abfrage oder einen Netzwerkpfad verantwortlich gemacht, der Pakete zwischen Ihrem Laptop und einer Cloud-Region auf der anderen Seite der Welt verwirft.

Bevor Sie Einstellungen ändern, führen Sie einen einfachen Test durch:

time ssh -vvv [email protected] exit

Die time-Ausgabe zeigt Ihnen, ob die gesamte Verbindung langsam ist. Die -vvv-Ausgabe zeigt Ihnen, wo der Client Zeit verbringt. Achten Sie auf wiederholte Schlüsselversuche, GSSAPI-Nachrichten, DNS-bedingte Pausen oder eine lange Lücke vor dem Start der Authentifizierung. Wenn ssh user@host exit schnell ist, aber ein interaktiver Login langsam ist, liegt das Problem wahrscheinlich in den Remote-Shell-Startdateien und nicht in SSH selbst.

Es gibt drei häufige Muster:

1. Langsam vor der Authentifizierung: Meistens DNS, GSSAPI, Host-Key-Lookup oder ein langsames Authentifizierungs-Backend.
2. Langsam nach der Authentifizierung, aber vor der Eingabeaufforderung: Meistens .bashrc, .profile, .zshrc, netzwerkmontierte Home-Verzeichnisse oder Shell-Plugins.
3. Langsam beim Tippen oder bei Verwendung von Vollbild-Tools: Meistens echte Netzwerklatenz, Paketverlust, überlastete Endpunkte, Komprimierungs-Overhead oder Terminal-Rendering.

Die folgenden Lösungen sind danach geordnet, wie oft sie echte SSH-Latenzprobleme lösen.

1. Reverse-DNS-Abfragen auf dem Server deaktivieren

Reverse-DNS ist eine klassische Ursache für langsame SSH-Logins in internen Netzwerken. Der Server akzeptiert Ihre TCP-Verbindung und versucht dann, die IP-Adresse des verbindenden Clients in einen Hostnamen aufzulösen. Wenn Reverse-DNS fehlt, falsch konfiguriert ist oder von einem langsamen Resolver bearbeitet wird, kann der Login mehrere Sekunden pausieren.

Dies ist eine serverseitige Einstellung. Fügen Sie diese Zeile in /etc/ssh/sshd_config hinzu oder aktualisieren Sie sie:

UseDNS no

Testen und laden Sie SSH dann neu:

sudo sshd -t
sudo systemctl reload sshd

Einige Distributionen verwenden ssh als Dienstnamen:

sudo systemctl reload ssh

Halten Sie Ihre bestehende Sitzung offen, während Sie einen neuen Login testen. Wenn der neue Login schnell ist, haben Sie die Verzögerung gefunden. Wenn sich nichts ändert, lassen Sie die Einstellung an Ort und Stelle, wenn sie zu Ihrer Umgebung passt, aber setzen Sie die Fehlersuche fort.

2. GSSAPI deaktivieren, wenn Sie Kerberos nicht verwenden

GSSAPI ist in Kerberos-gestützten Umgebungen nützlich. Außerhalb dieser Umgebungen kann es einen unnötigen Authentifizierungsversuch hinzufügen. Das Symptom ist normalerweise eine Pause während des Verbindungsaufbaus, bevor die Public-Key-Authentifizierung fortgesetzt wird.

Setzen Sie dies in Ihrer lokalen ~/.ssh/config:

Host *
    GSSAPIAuthentication no

Wenn Sie die Verzögerung nur bei einem Server sehen, begrenzen Sie die Einstellung auf diesen Host:

Host legacy-admin
    HostName legacy-admin.example.com
    User admin
    GSSAPIAuthentication no

Führen Sie ssh -vvv legacy-admin aus und vergleichen Sie vorher und nachher. Sie sollten sehen, dass der Client GSSAPI überspringt und direkt zur Public-Key- oder Passwort-Authentifizierung übergeht.

3. Hören Sie auf, die falschen Schlüssel anzubieten

Wenn Ihr SSH-Agent einen Haufen Schlüssel hält, kann Ihr Client mehrere Identitäten anbieten, bevor er diejenige erreicht, die der Server akzeptiert. Das ist langsamer als nötig, und einige Server lehnen den Login nach zu vielen fehlgeschlagenen Angeboten ab.

Die ausführliche Ausgabe macht dies deutlich:

debug1: Offering public key: /Users/me/.ssh/id_personal
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_old_vendor
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_prod

Fixieren Sie die richtige Identität:

Host prod-api
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

IdentitiesOnly yes ist wichtig. Ohne sie kann der Client immer noch Agent-Schlüssel vor oder neben der konfigurierten Datei anbieten.

Sie können auch überprüfen, was der Agent geladen hat:

ssh-add -l

Wenn die Liste unübersichtlich ist, entfernen Sie alte Schlüssel aus dem Agenten und fügen Sie nur das hinzu, was Sie für die aktuelle Arbeit benötigen:

ssh-add -D
ssh-add ~/.ssh/id_ed25519_prod

4. Komprimierung nur dort verwenden, wo sie hilft

Komprimierung ist kein universeller Geschwindigkeitsschalter. Sie kann helfen, wenn die Verbindung bandbreitenbegrenzt ist und die Daten komprimierbar sind, wie z.B. lange Textprotokolle über ein langsames VPN. Sie kann in schnellen Netzwerken schaden, weil beide Seiten CPU-Zeit für das Komprimieren und Dekomprimieren von Daten aufwenden, die sonst schnell über die Leitung gegangen wären.

Verwenden Sie sie gezielt:

Host distant-bastion
    HostName bastion.example.net
    User ops
    Compression yes

Aktivieren Sie sie nicht global, es sei denn, Sie haben gemessen, dass sie Ihren täglichen Verbindungen hilft. Für normales Cloud-zu-Laptop-SSH ist die Standardeinstellung oft besser.

Wenn das Tippen langsam ist, ist Komprimierung selten die erste Lösung. Testen Sie den Netzwerkpfad:

ping server.example.com
mtr server.example.com

Wenn Sie hohe Latenz oder Paketverlust sehen, kann die SSH-Konfiguration nur begrenzt helfen. Gehen Sie über einen näheren Bastion-Host, beheben Sie den VPN-Pfad oder verwenden Sie eine Region näher am Betreiber.

5. Verbindungen mit Multiplexing wiederverwenden

Wenn die erste SSH-Verbindung ein paar Sekunden dauert, aber jeder neue Terminal-Tab diese Kosten wiederholt, ist Verbindungsmultiplexing eine saubere Lösung. SSH hält eine Steuerverbindung offen und verwendet sie für spätere Sitzungen zum selben Benutzer, Host und Port wieder.

Fügen Sie dies zu ~/.ssh/config hinzu:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/controlmasters/%r@%h:%p
    ControlPersist 10m

Erstellen Sie das Socket-Verzeichnis:

mkdir -p ~/.ssh/controlmasters
chmod 700 ~/.ssh/controlmasters

Die erste Verbindung zahlt immer noch den normalen Handshake- und Authentifizierungsaufwand. Die nächste sollte sich fast sofort anfühlen.

Wenn eine multiplexte Verbindung nach einer Netzwerkänderung hängen bleibt, schließen Sie den Master-Socket:

ssh -O exit [email protected]

Oder entfernen Sie den passenden Socket aus ~/.ssh/controlmasters.

Überprüfen Sie den Shell-Start, bevor Sie SSH die Schuld geben

Dies ist leicht zu übersehen. SSH kann schnell authentifizieren, dann verbrennen Ihre Shell-Startdateien mehrere Sekunden, bevor die Eingabeaufforderung erscheint.

Vergleichen Sie diese:

time ssh [email protected] true
time ssh [email protected] 'bash --noprofile --norc -i -c exit'

Überprüfen Sie dann .bashrc, .bash_profile, .profile, .zshrc und alles, was sie einbinden. Häufige Verlangsamungen sind Eingabeaufforderungs-Designs, die Git-Befehle in großen Verzeichnissen ausführen, kubectl- oder Cloud-CLI-Vervollständigungen, die eine Remote-API abfragen, Paketmanager-Initialisierung, blockierte NFS-Home-Verzeichnisse und Skripte, die während des Logins interne Dienste aufrufen.

Die schnellste SSH-Lösung ist die, die zu der Pause passt, die Sie tatsächlich sehen können. Verwenden Sie -vvv, ändern Sie jeweils eine Sache und testen Sie von einem zweiten Terminal aus, während Sie Ihre aktuelle Sitzung offen lassen.