Connexions SSH lentes : identifier les causes avec tcpdump, ssh -vvv et vérifications MTU

«Pourquoi un login SSH prend‑il 10–30 secondes alors que le ping est propre ?» Si vous êtes confronté à des connexions SSH lentes, une approche par phases aide : d’abord déterminer dans quelle phase le délai se produit, ensuite côté client limiter avec ssh -vvv, puis contrôler le transport avec tcpdump et enfin tester MTU/PMTUD. MTU = Maximum Transmission Unit (taille maximale du paquet) ; PMTUD = Path MTU Discovery (mécanisme par lequel l’émetteur détermine la taille maximale de paquet utilisable). En environnements productifs, les causes typiques sont DNS/reverse‑DNS, GSSAPI/Kerberos, expirations PAM/annuaire, pertes silencieuses de paquets sur des tronçons VPN/overlay et MTU-Blackholes.

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

SSH peut être divisé en cinq phases pertinentes : établissement de la connexion TCP, SSH‑Kex/handshake (échange de clés), authentification (clé publique, mot de passe, GSSAPI), configuration de la session/PTY et transfert de données ultérieur. La cause détermine dans quelle phase le délai est visible — mesurez spécifiquement cette phase, pas seulement la latence totale.

• Vor Passwort/Key: souvent DNS ou GSSAPI ; les délais surviennent lors de la résolution de noms ou de l’obtention d’un ticket Kerberos.
• Während Authentifizierung: AuthorizedKeysCommand externe, LDAP/SSSD ou modules PAM peuvent provoquer des timeouts.
• Nach Auth, vor Shell: scripts de login côté serveur, allocation de PTY ou problèmes réseau/MTU.
• Im Datentransfer: perte de paquets, PMTU‑Blackholes, QoS/traffic‑shaping ou problèmes de fenêtre TCP/tcp windowing.

Prüfsequenz: Strukturierte Vorgehensweise

Une séquence de vérification fixe économise du temps et réduit les changements involontaires. Ordre recommandé :

1. Client : ssh -vvv et contrôles de base (IP au lieu de nom d’hôte, GSSAPI désactivé).
2. Serveur : logs sshd, sshd -T, vérifier PAM/SSSD/AuthorizedKeysCommand.
3. Réseau : tcpdump sur client, serveur (et bastion) pour captures TCP et ICMP.
4. MTU/PMTUD : ip link, DF‑Ping, éventuellement MSS‑clamping comme contournement.
5. Kubernetes : vérifier la CNI‑MTU, utiliser un DaemonSet pour les tests.

Clientseitiges Debugging mit ssh -vvv

ssh -vvv affiche la timeline d’exécution du client. La sortie contient des progressions temporelles et des pauses que vous pouvez utiliser comme indicateur de la phase concernée. Si vous voyez des trous, notez les horodatages — cela facilite la corrélation avec tcpdump ou les logs serveur.

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.“ → scripts de login côté serveur, configuration PTY ou MTU‑Blackhole où le premier paquet à charge utile plus importante n’arrive pas.

GSSAPI / Kerberos schnell prüfen

Dans de nombreux environnements d’entreprise, GSSAPI (Single‑Sign‑On via Kerberos) est activé. Si le KDC n’est pas joignable ou si le DNS est mal configuré, le client attend. Testez temporairement :

ssh -vvv -o GSSAPIAuthentication=no user@zielhost

Si cela est sensiblement plus rapide, vérifiez l’accessibilité du KDC, du DNS et du NTP. Attention : dans des environnements qui exigent le SSO, désactiver GSSAPI n’est qu’un contournement temporaire.

DNS- und PTR-Checks

sshd effectue fréquemment des reverse‑DNS lookups (PTR) du client. Des PTR lents ou manquants provoquent des délais. Testez directement par 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

Si la résolution PTR est lente, corrigez le DNS/les zones ou définissez dans /etc/ssh/sshd_config UseDNS no si les PTR posent des problèmes persistants. Testez toujours avec sshd -t avant de recharger.

Vérifications serveur : sshd, PAM et AuthorizedKeysCommand

Sur l’hôte cible, les pistes de contrôle habituelles : les logs sshd, les timeouts PAM/SSSD et les scripts externes AuthorizedKeysCommand (qui récupèrent les clés publiques depuis des bases de données). Si des délais d’attente y sont constatés, corrigez la cause ou ajoutez des timeouts/mise en 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"

Si AuthorizedKeysCommand effectue des appels API externes, vérifiez latence, timeouts et mécanismes de repli. La mise en cache et des repli locaux réduisent l’impact en cas de panne de l’API.

Diagnostic réseau avec tcpdump : motifs typiques et interprétation

tcpdump met en évidence les retransmissions, ACKs manquants ou messages ICMP d’erreur — précisément les indices qui révèlent des problèmes MTU/PMTUD ou de perte de paquets. Les captures doivent être réalisées aux deux extrémités (client et serveur) pour comparaison.

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

Observations typiques :

• Numéros de séquence identiques répétés → retransmissions → perte de paquets sur le trajet.
• TCP SYN envoyé, SYN-ACK reçu, longue pause avant l’ACK → perte de paquets dans une direction du trajet.
• ICMP Type 3 Code 4 (IPv4 „Fragmentation Needed“) ou ICMPv6 „Packet Too Big“ → information PMTUD présente ; l’émetteur peut adapter la MTU.
• Absence de messages ICMP malgré l’échec de DF-ping → PMTUD-Blackhole (souvent causé par un pare-feu, NAT ou tunnel bloquant ICMP).

Extrait tcpdump exemplaire et signification :

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)

Ici, la longue pause et la retransmission qui suit indiquent une perte de paquets ou un drop. Si, à la place, suit un ICMP „Fragmentation Needed“, la cause est la fragmentation.

Vérifications MTU : étapes concrètes

Les problèmes de MTU sont fréquents dans les environnements avec encapsulation (VPN, WireGuard, VXLAN, GRE). Étapes de vérification :

1) Vérifier la MTU des interfaces

ip link show

Tenez compte des interfaces tunnel/overlay telles que wg0, tun0, vxlan0 ou des devices CNI (cni0, flannel.1). La MTU de chemin effective = la plus petite MTU moins l’overhead d’encapsulation.

2) DF-ping pour déterminer la MTU du chemin

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

Si de grands DF-pings échouent, réduisez la taille progressivement jusqu’à obtenir des réponses — cela indique la MTU réelle du chemin.

3) MSS-Clamping als pragmatischer Workaround

Si ICMP est bloqué sur le trajet (PMTUD-Blackhole), le MSS-Clamping réduit la longueur des données utiles négociée lors du handshake TCP. Exemple avec 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

Avec 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

Remarque : le MSS-Clamping ne corrige que TCP ; les protocoles basés sur UDP RESTent affectés. Appliquez cette mesure de manière ciblée en bordure du trajet problématique et consignez-la dans le Change-Log.

Kubernetes: spezielle Prüf- und Betriebs-Hinweise

Les clusters Kubernetes utilisent souvent des réseaux overlay (VXLAN, Geneve) ou des host-networks avec des CNI-Devices. Ceux-ci ajoutent des en-têtes supplémentaires et réduisent la MTU effective. De plus, dans de nombreuses entreprises, la politique ICMP est RESTrictive, ce qui perturbe la PMTUD.

Praxis: MTU und tcpdump in einem Cluster prüfen

Déployez le test via un DaemonSet ou un Pod de débogage temporaire sur tous les nœuds pour vous assurer que tout le trajet est testé.

# 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

En alternative, déployez un DaemonSet exécutant tcpdump, centralisez la collecte des pcaps et comparez nœud à nœud. Faites attention aux droits et à la protection des données — les PCAPs peuvent contenir des informations sensibles.

Monitoring, Automatisierung und Prävention

Pour éviter la réapparition d’incidents, une combinaison de Monitoring et de mesures préventives est recommandée :

• Mesure de la latence de connexion SSH : un check synthétique simple qui établit périodiquement une connexion et mesure le temps jusqu’au prompt. Exemple de script ci-dessous.
• Checks de santé réseau : vérifier régulièrement le Path-MTU et la disponibilité d’ICMP.
• Alerting: Wenn SSH-Login-Latenz > x Sekunden oder Retransmits/ICMP-Errors in tcpdump auftreten, Ticket aufmachen.
• Documentation : consignez tous les contournements temporaires (MSS-Clamp, modifications de MTU, UseDNS) dans le Change-Log et attribuez un propriétaire.

Exemple de script pour la mesure synthétique de la latence SSH (BatchMode empêche la saisie de mot de passe) :

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

Toutes les interventions doivent être réversibles et testées. Règles de base :

• Vérifiez les modifications de /etc/ssh/sshd_config avec sshd -t et testez-les dans une seconde session admin avant de fermer les sessions existantes.
• Assignez une durée de validité aux règles de pare-feu et iptables ou déployez-les via un gestionnaire de configuration, de sorte qu’un revert automatique soit possible.

Pièges pratiques

Erreurs typiques qui coûtent du temps :

• Captures tcpdump unilatérales : le routage asymétrique conduit à des conclusions erronées. Capturer toujours à plusieurs points.
• ICMP bloqué sur des pare‑feux sans documentation : PMTUD s’effondre sans erreur évidente.
• AuthorizedKeysCommand sans timeout/cache : une panne d’API externe bloque les connexions.
• Définir MSS‑Clamp globalement sans documentation : des problèmes de performance ultérieurs restent inexpliqués.

Résumé / Conclusion

Grâce à une analyse par phases, les connexions SSH lentes deviennent maîtrisables : utilisez ssh -vvv pour identifier la phase concernée ; tcpdump révèle les indicateurs de transport et de PMTUD ; les DF‑ping et vérifications MTU fournissent la MTU du chemin. Dans les environnements Kubernetes et VPN, MTU/PMTUD sont particulièrement critiques, car les encapsulations réduisent la taille effective des paquets et les messages ICMP sont souvent bloqués. Appliquez des contournements pragmatiques et documentés (MSS‑Clamping, adaptation temporaire de la MTU des tunnels) et planifiez parallèlement la correction de la cause racine (DNS‑PTR, politique ICMP, stabilisation KDC/NTP). Un runbook court et reproductible ainsi que des contrôles synthétiques automatisés empêchent les récurrences et réduisent le coût des incidents.

Liste de vérification pour tests et runbook (version courte)

• Documenter la reproduction (client, heure, chemin).
• Exécuter ssh -vvv, noter la phase.
• Tester l’IP au lieu du nom d’hôte ; désactiver temporairement GSSAPI.
• Serveur : vérifier les logs, sshd -T, AuthorizedKeysCommand/LDAP/SSSD‑Timeouts.
• tcpdump aux deux extrémités : filtre SSH + ICMP.
• Vérifier la MTU : ip link, DF‑Ping, MSS‑Clamp uniquement après analyse.
• Dans Kubernetes : vérifier le CNI‑MTU sur tous les nœuds, utiliser des Debug‑Pods/DaemonSet.
• Documenter les modifications et les rendre réversibles.

Perspective architecture et exploitation : pourquoi les connexions SSH lentes deviennent systémiques

Outre les erreurs isolées, les connexions SSH lentes sont souvent le symptôme d’incohérences architecturales ou opérationnelles. Des considérations au‑delà des captures de paquets aident à planifier des solutions durables : les load‑balancers, NAT‑gateways, firewalls stateful, fournisseurs SD‑WAN et cloud security groups modifient le comportement de TCP/SYN, peuvent supprimer l’ICMP ou provoquer un routage asymétrique. Documentez le chemin complet (Client → zones → bastion → cible) et vérifiez quelles composants terminent ou proxient activement le TCP.

Commandes de vérification pour effets d’infrastructure

Quelques contrôles simples révèlent souvent des influences cachées :

# 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

Causes opérationnelles typiques et risques

• Les NIC‑offloads (GRO/LRO/TSO) peuvent modifier l’ordre et la taille des paquets visibles ; désactivez‑les temporairement pour le débogage, mais seulement brièvement — la performance peut en pâtir sinon.
• Les SYN‑proxies ou la terminaison TCP sur des LB déplacent le timing du handshake : vérifiez si le proxy applique des timeouts supplémentaires.
• L’épuisement du conntrack empêche les nouvelles connexions ou augmente les retransmissions ; les modifications de nf_conntrack_max nécessitent planification et monitoring.

Directives opérationnelles et intégration

Planifiez les modifications comme des étapes simples et réversibles : déploiement canari (une passerelle), mesure avant/après (SYN‑Latency, tcp_retrans) et automatisation via la gestion de configuration. Intégrez les scripts de vérification et la collecte tcpdump dans vos CI/CD‑Runbooks, afin que le débogage soit reproductible et que les responsabilités soient clairement définies. Veillez à la protection des données des PCAPs et à l’attribution explicite d’un responsable pour les contournements temporaires tels que MSS‑Clamping ou les modifications de UseDNS.

En bref : ne considérez pas les connexions SSH lentes uniquement comme un problème isolé, mais comme un indicateur de l’architecture réseau et opérationnelle. Ce n’est qu’ainsi que des solutions évolutives, documentées et réversibles peuvent être mises en œuvre.

Pour ce sujet, Tcpdump Ssh et Mtu Check sont également importants. Le présent article met ces aspects en perspective de façon compréhensible et montre ce qui importe au quotidien.