Langsame SSH-Verbindungen: Ursachen finden mit tcpdump, ssh -vvv und MTU-Checks

„Warum dauert ein SSH-Login 10–30 Sekunden, obwohl Ping sauber ist?“ Wenn Sie mit langsame SSH-Verbindungen konfrontiert sind, hilft ein phasenbasiertes Vorgehen: Zuerst klären, in welcher Phase die Verzögerung auftritt, dann clientseitig mit ssh -vvv grob eingrenzen, anschließend mit tcpdump den Transport prüfen und zuletzt MTU/PMTUD testen. MTU = Maximum Transmission Unit (maximale Paketgröße); PMTUD = Path MTU Discovery (Mechanismus, mit dem Sender die maximale nutzbare Paketgröße erkennt). In produktiven Umgebungen sind typische Ursachen DNS/Reverse-DNS, GSSAPI/Kerberos, PAM/Directory-Timeouts, stille Paketverluste auf VPN-/Overlay-Strecken und MTU-Blackholes.

Kurzüberblick: In welcher Phase tritt Verzögerung auf?

SSH lässt sich in fünf sinnvolle Phasen unterteilen: TCP-Verbindungsaufbau, SSH-Kex/Handshake (Key Exchange), Authentifizierung (Public Key, Password, GSSAPI), Session-/PTY-Setup und anschließender Datentransfer. Die Ursache bestimmt, in welcher Phase die Verzögerung sichtbar wird — messen Sie gezielt diese Phase, nicht nur die Gesamtlatenz.

• Vor Passwort/Key: oft DNS oder GSSAPI; Verzögerungen treten während Name-Resolution oder Kerberos-Ticket-Erhalt auf.
• Während Authentifizierung: externe AuthorizedKeysCommand, LDAP/SSSD oder PAM-Module können Zeitüberschreitungen erzeugen.
• Nach Auth, vor Shell: serverseitige Login-Scripte, PTY-Allocation oder Netzwerk/MTU-Probleme.
• Im Datentransfer: Paketverlust, PMTU-Blackholes, QoS/Traffic-Shaping oder TCP-Fenster/Windowing-Probleme.

Prüfsequenz: Strukturierte Vorgehensweise

Eine feste Prüfsequenz spart Zeit und reduziert unbeabsichtigte Changes. Empfohlene Reihenfolge:

1. Client: ssh -vvv und Basis-Checks (IP statt Hostname, GSSAPI aus).
2. Server: sshd-Logs, sshd -T, PAM/SSSD/AuthorizedKeysCommand prüfen.
3. Netzwerk: tcpdump auf Client, Server (und Bastion) für TCP- und ICMP-Mitschnitte.
4. MTU/PMTUD: ip link, DF-Ping, ggf. MSS-Clamping als Workaround.
5. Kubernetes: CNI-MTU prüfen, DaemonSet für Tests verwenden.

Clientseitiges Debugging mit ssh -vvv

ssh -vvv zeigt die Ablauf-Timeline des Clients. Die Ausgabe enthält zeitliche Fortschritte und Pausen, die Sie als Indikator für die betroffene Phase nutzen. Wenn Sie Lücken sehen, notieren Sie Zeitstempel — das erleichtert die Korrelation mit tcpdump- oder Server-Logs.

ssh -vvv user@zielhost

Worauf achten:

• „Resolving host…“ oder lange Zeit bis „Connecting to …“ → DNS/Netzwerk.
• Pause bei „Authentications that can continue…“ → GSSAPI/Kerberos oder PAM/Directory-Timeout.
• Delay nach „Entering interactive session.“ → serverseitige Login-Scripts, PTY-Setup oder MTU-Blackhole, das erste Paket mit größerer Nutzlast nicht ankommt.

GSSAPI / Kerberos schnell prüfen

In vielen Enterprise-Setups ist GSSAPI (Single-Sign-On via Kerberos) aktiviert. Wenn der KDC nicht erreichbar ist oder DNS falsch konfiguriert, wartet der Client. Testen Sie temporär:

ssh -vvv -o GSSAPIAuthentication=no user@zielhost

Wenn das deutlich schneller ist, prüfen Sie KDC-, DNS- und NTP-Erreichbarkeit. Vorsicht: In Umgebungen, die SSO benötigen, ist Deaktivieren nur ein temporärer Workaround.

DNS- und PTR-Checks

sshd führt häufig Reverse-DNS-Lookups (PTR) des Client-Hosts durch. Langsame oder fehlende PTRs führen zu Verzögerungen. Testen Sie direkt per IP:

ssh -vvv user@203.0.113.10

# Auf dem SSH-Server prüfen:
getent hosts 198.51.100.27
# oder
dig -x 198.51.100.27 +time=2 +tries=1

Löst die PTR-Auflösung langsam, korrigieren Sie DNS/Zonen oder setzen Sie in /etc/ssh/sshd_config UseDNS no, wenn Kopfzerbrechen mit PTRs andauert. Testen immer mit sshd -t vor Reload.

Server-Checks: sshd, PAM und AuthorizedKeysCommand

Auf dem Zielhost sind die üblichen Prüfpfade: sshd-Logs, PAM/SSSD-Timeouts und externe AuthorizedKeysCommand-Skripte (diese holen Public Keys aus Datenbanken). Finden sich dort Wartezeiten, beheben Sie die Ursache oder fügen Timeouts/Cache hinzu.

# Logs anzeigen
sudo journalctl -u ssh -S "-30min" --no-pager
# oder
tail -n 200 /var/log/auth.log

# Effektive sshd-Konfiguration prüfen
sudo sshd -T | egrep -i "gssapi|usedns|usepam|authorizedkeyscommand|login"

Wenn AuthorizedKeysCommand externe API-Aufrufe durchführt, prüfen Sie Latenz, Timeouts und Fallbacks. Cachen und lokale Fallbacks reduzieren Auswirkung bei API-Ausfällen.

Netzwerkdiagnose mit tcpdump: typische Muster und Interpretation

tcpdump macht Retransmits, fehlende ACKs oder ICMP-Fehlermeldungen sichtbar — genau die Hinweise, die MTU/PMTUD-Probleme oder Paketverlust verraten. Mitschnitte gehören an beide Enden (Client und Server) für Vergleich.

# Enger Mitschnitt: nur SSH-Verkehr
sudo tcpdump -i any -nn -s 96 -w /tmp/ssh-slow.pcap "host 198.51.100.27 and tcp port 22"
# Parallel ICMP/Meldungen
sudo tcpdump -i any -nn -s 96 "icmp or icmp6"
# TShark (CLI) für schnelle Analyse
sudo tshark -r /tmp/ssh-slow.pcap -q -z io,stat,0, "tcp.analysis.retransmission or icmp"

Typische Beobachtungen:

• Wiederholte gleiche Sequenznummern → Retransmits → Paketverlust auf dem Pfad.
• TCP-SYN gesendet, SYN-ACK empfangen, lange Pause bis ACK → Paketverlust in einem Richtungsteil.
• ICMP Type 3 Code 4 (IPv4 „Fragmentation Needed“) oder ICMPv6 „Packet Too Big“ → PMTUD-Info vorhanden; Sender kann MTU anpassen.
• Fehlen der ICMP-Meldungen trotz DF-Ping-Fehler → PMTUD-Blackhole (oft durch Firewall, NAT oder Tunnel, die ICMP blockieren).

Ein beispielhafter tcpdump-Auszug und die Bedeutung:

12:00:01.123456 IP 10.0.0.1.54321 > 10.0.0.2.22: Flags [P.], seq 1:1449, ack 1, win 229, length 1448
12:00:01.234567 IP 10.0.0.2.22 > 10.0.0.1.54321: Flags [.], ack 1449, win 65535, length 0
12:00:10.345678 IP 10.0.0.1.54321 > 10.0.0.2.22: Flags [P.], seq 1:1449, ack 1, win 229, length 1448 (retransmission)

Hier zeigt die lange Pause und anschließende Retransmission Paketverlust oder Drop. Wenn stattdessen eine ICMP „Fragmentation Needed“ folgt, ist die Ursache Fragmentierung.

MTU-Checks: konkrete Schritte

MTU-Probleme sind in Umgebungen mit Kapselung (VPN, WireGuard, VXLAN, GRE) sehr häufig. Prüfschritte:

1) Interface-MTU prüfen

ip link show

Beachten Sie Tunnel-/Overlay-Interfaces wie wg0, tun0, vxlan0 oder CNI-Devices (cni0, flannel.1). Die effektive Pfad-MTU = kleinste MTU minus Kapsel-Overhead.

2) DF-Ping zur Pfad-MTU-Bestimmung

# Beispiel IPv4: 1472 payload entspricht MTU1500 (1500-28)
ping -c 3 -M do -s 1400 zielhost
ping -c 3 -M do -s 1472 zielhost

Wenn große DF-Pings fehlschlagen, reduzieren Sie die Größe schrittweise, bis Antworten kommen — das zeigt die tatsächliche Pfad-MTU.

3) MSS-Clamping als pragmatischer Workaround

Wenn ICMP auf dem Pfad blockiert ist (PMTUD-Blackhole), reduziert MSS-Clamping die beim TCP-Handshake verhandelte Nutzdatenlänge. Beispiel mit iptables:

# MSS-Clamping am Gateway (nur TCP SYN)
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Mit nftables:

# nftables Beispiel
sudo nft add table inet mangle
sudo nft 'add chain inet mangle forward { type filter hook forward priority 0 ; }'
sudo nft add rule inet mangle forward tcp flags syn tcp option maxseg size set rt --clamp-mss-to-pmtu

Hinweis: MSS-Clamping korrigiert nur TCP; UDP-basierte Protokolle bleiben betroffen. Setzen Sie diese Maßnahme fokussiert am Rand des problematischen Pfads und dokumentieren Sie sie im Change-Log.

Kubernetes: spezielle Prüf- und Betriebs-Hinweise

Kubernetes-Cluster verwenden oft Overlay-Netze (VXLAN, Geneve) oder host-networks mit CNI-Devices. Diese erzeugen zusätzlichen Header und reduzieren die effektive MTU. Außerdem ist in vielen Firmen die ICMP-Policy restriktiv, was PMTUD stört.

Praxis: MTU und tcpdump in einem Cluster prüfen

Verteilen Sie den Test per DaemonSet oder temporärem Debug-Pod auf allen Nodes, um sicherzustellen, dass die gesamte Route geprüft ist.

# Beispiel: Debug-Pod auf einem Node starten
kubectl run -it --rm ssh-debug --image=alpine --overrides='{"spec":{"containers":[{"name":"c","image":"alpine","command":["/bin/sh","-c","apk add --no-cache iproute2 tcpdump bind-tools; sleep 3600"]}],"hostNetwork":true}}' --restart=Never

# Im Pod:
ip link show
ping -c 3 -M do -s 1400 10.244.0.5
tcpdump -i any -n -s 96 'tcp port 22' -w /tmp/ssh-node.pcap

Alternativ verteilen Sie einen DaemonSet mit tcpdump, sammeln die pcaps zentral und vergleichen Node-zu-Node. Achten Sie auf Berechtigungen und Datenschutz — PCAPs können sensible Inhalte enthalten.

Monitoring, Automatisierung und Prävention

Um erneute Vorfälle zu verhindern, empfiehlt sich eine Kombination aus Monitoring und präventiven Maßnahmen:

• Messung der SSH-Login-Latenz: Ein einfacher Synthetik-Check, der periodisch eine Verbindung aufbaut und die Zeit bis zum Prompt misst. Skript-Beispiel unten.
• Netzwerk-Health-Checks: Pfad-MTU-Checks und ICMP-Verfügbarkeit regelmäßig prüfen.
• Alerting: Wenn SSH-Login-Latenz > x Sekunden oder Retransmits/ICMP-Errors in tcpdump auftreten, Ticket aufmachen.
• Dokumentation: Alle temporären Workarounds (MSS-Clamp, MTU-Änderungen, UseDNS) im Change-Log und mit Owner versehen.

Beispiel-Skript für synthetische SSH-Latenz-Messung (BatchMode verhindert Passworteingabe):

#!/bin/bash
# ssh-latency-check.sh
TARGET=$1
if [ -z "$TARGET" ]; then
  echo "Usage: $0 user@host"
  exit 1
fi
START=$(date +%s%3N)
ssh -o BatchMode=yes -o ConnectTimeout=10 -o PasswordAuthentication=no -q $TARGET exit
RC=$?
END=$(date +%s%3N)
DUR=$((END-START))
if [ $RC -eq 0 ]; then
  echo "ok $TARGET $DUR ms"
  exit 0
else
  echo "fail $TARGET $DUR ms (rc=$RC)"
  exit 2
fi

Rollback- und Sicherheitsstrategie

Alle Eingriffe müssen reversibel und getestet sein. Grundregeln:

• Änderungen an /etc/ssh/sshd_config mit sshd -t prüfen und in einer zweiten Admin-Session testen, bevor alte Sessions beendet werden.
• Firewall- und iptables-Regeln mit Ablauf versehen oder über Konfigurationsmanagement deployen, sodass ein automatischer Revert möglich ist.
• PCAPs und Logs datenschutzkonform behandeln: kurzlebig speichern, verschlüsselt ablegen oder Anonymisierung nutzen.
• Produktive MTU-Änderungen auf Tunnels/Interfaces in Wartungsfenstern und mit Messtools begleiten.

Praktische Stolperfallen

Typische Fehler, die Zeit kosten:

• Einseitige tcpdump-Mitschnitte: Asymmetrisches Routing führt zu falschen Schlussfolgerungen. Immer an mehreren Punkten mitschneiden.
• ICMP blockiert auf Firewalls, aber nicht dokumentiert: PMTUD bricht zusammen, ohne offensichtliche Fehler.
• AuthorizedKeysCommand ohne Timeout/Cache: externe API-Ausfall blockiert Login.
• MSS-Clamp global setzen ohne Dokumentation: spätere Performance-Probleme bleiben unerklärt.

Zusammenfassung / Fazit

Mit einer phasenbasierten Analyse werden langsame SSH-Verbindungen beherrschbar: Nutzen Sie ssh -vvv, um die betroffene Phase zu identifizieren; tcpdump zeigt Transport- und PMTUD-Indikatoren; DF-Pings und MTU-Checks liefern die Pfad-MTU. In Kubernetes- und VPN-Umgebungen sind MTU/PMTUD besonders relevant, weil Kapselungen die effektive Paketgröße reduzieren und ICMP-Meldungen oft blockiert werden. Setzen Sie pragmatische, dokumentierte Workarounds (MSS-Clamping, temporäre Tunnel-MTU-Anpassung) und planen Sie parallel den Root-Cause-Fix (DNS-PTR, ICMP-Policy, KDC/NTP-Stabilisierung). Ein kurzes, reproduzierbares Runbook und automatisierte Synthetik-Checks verhindern Wiederholung und reduzieren Incident-Aufwand.

Prüf- und Runbook-Checkliste (Kurzversion)

• Reproduktion dokumentieren (Client, Zeit, Pfad).
• ssh -vvv ausführen, Phase notieren.
• IP statt Hostname testen; GSSAPI temporär deaktivieren.
• Server: Logs prüfen, sshd -T, AuthorizedKeysCommand/LDAP/SSSD-Timeouts.
• tcpdump an beiden Enden: SSH-Filter + ICMP.
• MTU prüfen: ip link, DF-Ping, MSS-Clamp nur nach Analyse.
• In Kubernetes: CNI-MTU auf allen Nodes prüfen, Debug-Pods/DaemonSet verwenden.
• Änderungen dokumentieren und rollback-fähig gestalten.

Architektur- und Betriebsblick: Warum langsame SSH-Verbindungen systemisch werden

Neben Einzelfehlern sind langsame SSH-Verbindungen oft ein Symptom für architektonische oder betriebliche Inkonsistenzen. Betrachtungen, die über Paketmitschnitte hinausgehen, helfen, dauerhafte Lösungen zu planen: Load-Balancer, NAT‑Gateways, Stateful-Firewalls, SD‑WAN-Provider und Cloud‑Security‑Groups verändern Verhalten von TCP/SYN, können ICMP eliminieren oder asymmetrisches Routing erzeugen. Documentieren Sie den vollständigen Pfad (Client → Zonen → Bastion → Ziel) und prüfen Sie, welche Komponenten TCP aktiv terminieren oder proxien.

Prüf-Commands für Infrastruktur-Effekte

Ein paar einfache Prüfungen zeigen oft versteckte Einflüsse:

# Offload-Funktionen prüfen (NIC/VM-Host)
ethtool -k eth0

# Kernel-Flags für MTU-Probing
sysctl net.ipv4.tcp_mtu_probing

# Conntrack-Auslastung (bei NAT/Firewalls relevant)
sudo sysctl net.netfilter.nf_conntrack_count
sudo sysctl net.netfilter.nf_conntrack_max

Typische operative Ursachen und Risiken

• NIC-Offloads (GRO/LRO/TSO) können die Reihenfolge und Größe sichtbarer Pakete verändern; bei Debugging temporär deaktivieren, aber nur kurz — Performance kann sonst leiden.
• SYN‑Proxies oder TCP‑Termination an LB schieben Handshake‑Timing: Prüfen Sie, ob der Proxy zusätzliche Timeouts hat.
• Conntrack‑Exhaustion stoppt neue Verbindungen oder erhöht Retransmits; Änderungen an nf_conntrack_max erfordern Planung und Monitoring.
• Cloud‑Provider blockieren ICMP defaultmäßig; ein permanenter Workaround (MSS‑Clamping) ist möglich, aber dokumentations‑ und testing‑pflichtig.

Betriebsleitlinien und Integration

Planen Sie Änderungen als einfache, rückrollbare Schritte: Canary‑Rollout (ein Gateway), Messung vor/nach (SYN‑Latency, tcp_retrans), und Automatisierung via Konfigurationsmanagement. Packen Sie Prüfskripte und tcpdump‑Sammlung in Ihre CI/CD‑Runbooks, damit Debugging reproduzierbar ist und Verantwortlichkeiten klar sind. Achten Sie auf Datenschutz bei PCAPs und auf explizite Owner für temporäre Workarounds wie MSS‑Clamping oder UseDNS‑Änderungen.

Kurz: Betrachten Sie langsame SSH‑Verbindungen nicht nur als Einzelproblem, sondern als Indikator für Netz‑ und Betriebsarchitektur. Nur so lassen sich skalierbare, dokumentierte und rückrollbare Lösungen implementieren.

Für dieses Thema sind auch Tcpdump Ssh und Mtu Check wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.