Connessioni SSH lente: individuare le cause con tcpdump, ssh -vvv e verifiche MTU

«Perché un login SSH impiega 10–30 secondi, pur avendo un ping regolare?» Se siete di fronte a connessioni SSH lente, aiuta un approccio per fasi: prima determinare in quale fase si manifesta il ritardo, poi restringere il campo sul client con ssh -vvv, quindi verificare il trasporto con tcpdump e infine testare MTU/PMTUD. MTU = Maximum Transmission Unit (dimensione massima del pacchetto); PMTUD = Path MTU Discovery (meccanismo con cui il mittente determina la massima dimensione di pacchetto utilizzabile). In ambienti di produzione le cause tipiche sono DNS/reverse-DNS, GSSAPI/Kerberos, timeout di PAM/Directory, perdite di pacchetti silenziose su tratte VPN/overlay e MTU-Blackhole.

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

SSH può essere suddiviso in cinque fasi utili per l’analisi: handshake TCP, SSH-Kex/handshake (Key Exchange), autenticazione (Public Key, Password, GSSAPI), setup della sessione/PTY e trasferimento dati successivo. La causa determina in quale fase il ritardo è visibile — misurate specificamente quella fase, non solo la latenza totale.

• Vor Passwort/Key: spesso DNS o GSSAPI; i ritardi avvengono durante la risoluzione dei nomi o l’ottenimento del ticket Kerberos.
• Während Authentifizierung: AuthorizedKeysCommand esterni, LDAP/SSSD o moduli PAM possono generare timeout.
• Nach Auth, vor Shell: script di login sul server, allocazione PTY o problemi di rete/MTU.
• Im Datentransfer: perdita di pacchetti, PMTU-Blackhole, QoS/traffic-shaping o problemi di finestra/TCP windowing.

Prüfsequenz: Strukturierte Vorgehensweise

Una sequenza di verifica fissa risparmia tempo e riduce cambiamenti imprevisti. Ordine raccomandato:

1. Client: ssh -vvv e controlli di base (IP invece di hostname, GSSAPI disabilitato).
2. Server: log di sshd, sshd -T, controllare PAM/SSSD/AuthorizedKeysCommand.
3. Rete: tcpdump su client, server (e bastion) per catture TCP e ICMP.
4. MTU/PMTUD: ip link, DF-Ping, eventualmente MSS-Clamping come workaround.
5. Kubernetes: verificare CNI-MTU, usare un DaemonSet per i test.

Clientseitiges Debugging mit ssh -vvv

ssh -vvv mostra la timeline delle azioni del client. L’output contiene progressi temporali e pause che potete usare come indicatore della fase interessata. Se osservate delle lacune, annotate i timestamp — questo facilita la correlazione con tcpdump o i log del server.

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 molti ambienti enterprise GSSAPI (Single-Sign-On tramite Kerberos) è abilitato. Se il KDC non è raggiungibile o il DNS è mal configurato, il client attende. Testate temporaneamente:

ssh -vvv -o GSSAPIAuthentication=no user@zielhost

Se questo è sensibilmente più veloce, verificate raggiungibilità di KDC, DNS e NTP. Attenzione: in ambienti che richiedono SSO disabilitare è solo una soluzione temporanea.

DNS- und PTR-Checks

sshd esegue spesso lookup DNS inversi (PTR) dell’host client. PTR lenti o mancanti causano ritardi. Testate direttamente 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

Se la risoluzione PTR è lenta, correggete DNS/zone oppure impostate in /etc/ssh/sshd_config UseDNS no se i PTR continuano a creare problemi. Verificate sempre con sshd -t prima del reload.

Server-Checks: sshd, PAM und AuthorizedKeysCommand

Sull’host di destinazione ci sono i percorsi di controllo abituali: log di sshd, timeout di PAM/SSSD e script esterni AuthorizedKeysCommand (questi recuperano le chiavi pubbliche da database). Se lì si riscontrano attese, risolvete la causa oppure aggiungete timeout/cache.

# 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"

Se AuthorizedKeysCommand esegue chiamate API esterne, verificate latenza, timeout e fallback. Cache e fallback locali riducono l’impatto in caso di guasti alle API.

Netzwerkdiagnose mit tcpdump: typische Muster und Interpretation

tcpdump rende visibili ritrasmissioni, ACK mancanti o messaggi di errore ICMP — esattamente gli indizi che indicano problemi di MTU/PMTUD o perdita di pacchetti. I capture vanno effettuati su entrambe le estremità (client e server) per confronto.

# 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"

Osservazioni tipiche:

• Numeri di sequenza ripetuti uguali → ritrasmissioni → perdita di pacchetti sul percorso.
• TCP-SYN inviato, SYN-ACK ricevuto, lunga pausa prima dell’ACK → perdita di pacchetti in una delle direzioni.
• ICMP Type 3 Code 4 (IPv4 „Fragmentation Needed“) o ICMPv6 „Packet Too Big“ → informazione PMTUD presente; il mittente può adattare la MTU.
• Assenza di messaggi ICMP nonostante il fallimento di DF-ping → PMTUD-Blackhole (spesso causato da firewall, NAT o tunnel che bloccano ICMP).

Esempio di estratto tcpdump e significato:

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)

Qui la lunga pausa e la successiva ritrasmissione indicano perdita o scarto di pacchetti. Se invece segue un ICMP „Fragmentation Needed“, la causa è la frammentazione.

MTU-Checks: konkrete Schritte

I problemi di MTU sono molto comuni in ambienti con incapsulamento (VPN, WireGuard, VXLAN, GRE). Passi di verifica:

1) Interface-MTU prüfen

ip link show

Prestare attenzione a interfacce tunnel/overlay come wg0, tun0, vxlan0 o dispositivi CNI (cni0, flannel.1). La MTU effettiva del percorso = MTU più piccola meno l’overhead di incapsulamento.

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

Se i ping DF di grandi dimensioni falliscono, riducete gradualmente la dimensione finché non arrivano risposte — questo indica la MTU effettiva del percorso.

3) MSS-Clamping come soluzione pragmatica

Se ICMP è bloccato sul percorso (PMTUD-Blackhole), MSS-Clamping riduce la lunghezza dei dati utile negoziata durante l’handshake TCP. Esempio con 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

Con 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

Nota: MSS-Clamping corregge solo TCP; i protocolli basati su UDP RESTano interessati. Applicate questa misura in modo mirato al bordo del percorso problematico e documentatela nel registro delle modifiche.

Kubernetes: avvertenze specifiche per verifica e operatività

I cluster Kubernetes utilizzano spesso reti overlay (VXLAN, Geneve) o host-network con dispositivi CNI. Queste introducono header aggiuntivi e riducono la MTU effettiva. Inoltre in molte aziende la policy ICMP è RESTrittiva, il che ostacola PMTUD.

Prassi: verificare MTU e tcpdump in un cluster

Distribuite il test tramite DaemonSet o un Pod di debug temporaneo su tutti i nodi, per assicurarvi che venga verificato l’intero percorso.

# 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

In alternativa distribuite un DaemonSet con tcpdump, raccogliete i pcap centralmente e confrontateli nodo per nodo. PRESTate attenzione ai permessi e alla protezione dei dati — i PCAP possono contenere informazioni sensibili.

Monitoraggio, automazione e prevenzione

Per prevenire il ripetersi di incidenti è consigliata una combinazione di monitoraggio e misure preventive:

• Misurazione della latenza di login SSH: un controllo sintetico semplice che apre periodicamente una connessione e misura il tempo fino al prompt. Esempio di script di seguito.
• Controlli di integrità della rete: verificare regolarmente la Path-MTU e la disponibilità di ICMP.
• Alerting: Se la latenza di login SSH > x secondi o appaiono retransmits/errori ICMP nei tcpdump, aprire un ticket.
• Documentazione: Tutti i workaround temporanei (MSS-Clamp, modifiche MTU, UseDNS) devono essere registrati nel registro delle modifiche e avere un owner assegnato.

Esempio di script per la misurazione sintetica della latenza SSH (BatchMode evita la richiesta di password):

#!/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

Strategia di rollback e sicurezza

Tutti gli interventi devono essere reversibili e testati. Regole fondamentali:

• Verificare le modifiche a /etc/ssh/sshd_config con sshd -t e testarle in una seconda sessione admin prima di terminare le sessioni esistenti.
• Assegnare una scadenza alle regole firewall e iptables oppure distribuirle tramite gestione della configurazione, in modo che sia possibile un revert automatico.

Insidie pratiche

Errori tipici che costano tempo:

• Registrazioni tcpdump unilaterali: il routing asimmetrico conduce a conclusioni errate. Registrare sempre in più punti del percorso.
• ICMP bloccato sui firewall ma non documentato: PMTUD si interrompe senza errori evidenti.
• AuthorizedKeysCommand senza timeout/cache: un guasto all’API esterna blocca il login.
• Impostare MSS-Clamp a livello globale senza documentazione: problemi di performance successivi rimangono senza spiegazione.

Riepilogo / Conclusione

Con un’analisi per fasi le connessioni SSH lente diventano gestibili: usate ssh -vvv per identificare la fase interessata; tcpdump mostra indicatori di trasporto e PMTUD; i ping con DF e i controlli MTU forniscono la Path-MTU. In ambienti Kubernetes e VPN MTU/PMTUD sono particolarmente rilevanti, perché le incapsulazioni riducono la dimensione effettiva dei pacchetti e i messaggi ICMP sono spesso bloccati. Applicate workaround pragmatici e documentati (MSS-Clamping, adattamento temporaneo della MTU del tunnel) e pianificate in parallelo la correzione della causa radice (DNS-PTR, policy ICMP, stabilizzazione KDC/NTP). Un runbook breve e riproducibile e controlli sintetici automatizzati prevengono le ricorrenze e riducono il carico dell’incident.

Lista di controllo per verifica e runbook (versione breve)

• Documentare la riproduzione (Client, orario, percorso).
• ssh -vvv eseguire, annotare la fase.
• Testare con l’IP anziché il nome host; disabilitare temporaneamente GSSAPI.
• Server: verificare i log, sshd -T, AuthorizedKeysCommand/LDAP/SSSD-timeout.
• tcpdump su entrambe le estremità: filtro SSH + ICMP.
• Controllare la MTU: ip link, DF-Ping, MSS-Clamp solo dopo analisi.
• In Kubernetes: verificare la CNI-MTU su tutti i nodi, usare Debug-Pods/DaemonSet.
• Documentare le modifiche e renderle rollbackabili.

Panoramica architetturale e operativa: perché le connessioni SSH lente diventano sistemiche

Oltre ai singoli errori, le connessioni SSH lente sono spesso un sintomo di incoerenze architetturali o operative. Considerazioni che vanno oltre le catture di pacchetti aiutano a pianificare soluzioni durature: Load-Balancer, NAT‑Gateways, Stateful-Firewalls, SD‑WAN-Provider e Cloud‑Security‑Groups modificano il comportamento di TCP/SYN, possono eliminare ICMP o generare routing asimmetrico. Documentate il percorso completo (Client → Zonen → Bastion → destinazione) e verificate quali componenti terminano o fanno proxy attivo per TCP.

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

Cause operative tipiche e rischi

• NIC-Offloads (GRO/LRO/TSO) possono modificare l’ordine e la dimensione dei pacchetti visibili; durante il debug disabilitarli temporaneamente, ma solo per brevi periodi — altrimenti le prestazioni ne risentono.
• SYN‑Proxies oder TCP‑Termination an LB schieben Handshake‑Timing: Prüfen Sie, ob der Proxy zusätzliche Timeouts hat.
• L’esaurimento del Conntrack blocca nuove connessioni o aumenta i retransmit; le modifiche a nf_conntrack_max richiedono pianificazione e monitoraggio.

Linee guida operative e integrazione

Pianificate le modifiche come passaggi semplici e reversibili: Canary‑Rollout (un gateway), misurazione prima/dopo (SYN‑Latency, tcp_retrans), e automazione tramite gestione delle configurazioni. Inserite script di verifica e la raccolta tcpdump nei vostri CI/CD‑Runbooks, in modo che il debug sia riproducibile e le responsabilità chiare. Prestate attenzione alla protezione dei dati nei PCAPs e a un responsabile esplicito per workaround temporanei come MSS‑Clamping o modifiche UseDNS.

In breve: non considerate le connessioni SSH lente solo come un problema isolato, ma come un indicatore dell’architettura di rete e operativa. Solo così è possibile implementare soluzioni scalabili, documentate e ripristinabili.

Per questo tema sono inoltre importanti Tcpdump Ssh e Mtu Check. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.