Conexiones SSH lentas: identificar causas con tcpdump, ssh -vvv y comprobaciones de MTU

“¿Por qué una conexión SSH tarda 10–30 segundos, aunque el Ping sea correcto?” Si se enfrenta a conexiones SSH lentas, ayuda un enfoque por fases: primero determinar en qué fase se produce la demora, luego acotar en el cliente con ssh -vvv, a continuación comprobar el transporte con tcpdump y, por último, probar MTU/PMTUD. MTU = Maximum Transmission Unit (tamaño máximo de paquete); PMTUD = Path MTU Discovery (mecanismo con el que el emisor detecta el tamaño máximo utilizable de paquete). En entornos productivos las causas típicas son DNS/Reverse-DNS, GSSAPI/Kerberos, PAM/Directory-Timeouts, pérdidas silenciosas de paquetes en tramos VPN/overlay y MTU-Blackholes.

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

SSH puede dividirse en cinco fases útiles: establecimiento de la conexión TCP, SSH-Kex/Handshake (intercambio de claves), autenticación (clave pública, contraseña, GSSAPI), configuración de la sesión/PTY y el posterior intercambio de datos. La causa determina en qué fase aparece la demora — mida específicamente esa fase, no solo la latencia total.

• Vor Passwort/Key: a menudo DNS o GSSAPI; las demoras aparecen durante la resolución de nombres o la obtención del ticket Kerberos.
• Während Authentifizierung: AuthorizedKeysCommand externo, LDAP/SSSD o módulos PAM pueden provocar timeouts.
• Nach Auth, vor Shell: scripts de login del servidor, asignación de PTY o problemas de red/MTU.
• Im Datentransfer: pérdida de paquetes, PMTU-Blackholes, QoS/traffic shaping o problemas de ventana TCP (TCP windowing).

Prüfsequenz: Strukturierte Vorgehensweise

Una secuencia de comprobación fija ahorra tiempo y reduce cambios involuntarios. Orden recomendado:

1. Cliente: ssh -vvv y comprobaciones básicas (IP en lugar de nombre, GSSAPI desactivado).
2. Servidor: logs de sshd, sshd -T, comprobar PAM/SSSD/AuthorizedKeysCommand.
3. Red: tcpdump en cliente, servidor (y bastión) para capturas TCP e ICMP.
4. MTU/PMTUD: ip link, DF-Ping, si procede MSS-Clamping como solución temporal.
5. Kubernetes: comprobar CNI-MTU, usar un DaemonSet para las pruebas.

Clientseitiges Debugging mit ssh -vvv

ssh -vvv muestra la línea temporal del cliente. La salida contiene progresos temporales y pausas que puede usar como indicador de la fase afectada. Si ve huecos, anote las marcas temporales — esto facilita la correlación con tcpdump o con los logs del servidor.

ssh -vvv user@zielhost

En qué fijarse:

• “Resolving host…” o mucho tiempo hasta “Connecting to …” → DNS/red.
• Pausa en “Authentications that can continue…” → GSSAPI/Kerberos o timeout de PAM/directorio.
• Retraso tras “Entering interactive session.” → scripts de login en el servidor, configuración de PTY o MTU-Blackhole, donde el primer paquete con mayor carga útil no llega.

GSSAPI / Kerberos schnell prüfen

En muchos entornos empresariales GSSAPI (Single Sign-On vía Kerberos) está activado. Si el KDC no es alcanzable o el DNS está mal configurado, el cliente espera. Pruebe temporalmente:

ssh -vvv -o GSSAPIAuthentication=no user@zielhost

Si esto es claramente más rápido, compruebe la accesibilidad del KDC, del DNS y del NTP. Precaución: en entornos que requieren SSO, desactivar esto es solo un workaround temporal.

DNS- und PTR-Checks

sshd suele realizar búsquedas DNS inversas (PTR) del host cliente. PTRs lentos o ausentes ocasionan demoras. Pruebe directamente por 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 resolución PTR es lenta, corrija DNS/zonas o configure en /etc/ssh/sshd_config UseDNS no si los PTR causan problemas. Siempre pruebe con sshd -t antes de recargar.

Comprobaciones del servidor: sshd, PAM y AuthorizedKeysCommand

En el host de destino están las rutas habituales de verificación: registros de sshd, tiempos de espera de PAM/SSSD y scripts externos de AuthorizedKeysCommand (estos recuperan claves públicas de bases de datos). Si allí se detectan esperas, corrija la causa o añada tiempos de espera/caché.

# 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 realiza llamadas a APIs externas, compruebe latencia, timeouts y mecanismos de reserva (fallbacks). El almacenamiento en caché y los fallbacks locales reducen el impacto en caso de fallos de la API.

Diagnóstico de red con tcpdump: patrones típicos e interpretación

tcpdump hace visibles retransmisiones, ACKs faltantes o mensajes de error ICMP — exactamente las indicaciones que delatan problemas de MTU/PMTUD o pérdida de paquetes. Las capturas deben realizarse en ambos extremos (cliente y servidor) para compararlas.

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

Observaciones típicas:

• Números de secuencia repetidos iguales → retransmisiones → pérdida de paquetes en el trayecto.
• TCP-SYN enviado, SYN-ACK recibido, larga pausa hasta el ACK → pérdida de paquetes en una de las direcciones del camino.
• ICMP Type 3 Code 4 (IPv4 „Fragmentation Needed“) o ICMPv6 „Packet Too Big“ → indica información de PMTUD; el remitente puede ajustar la MTU.
• Ausencia de mensajes ICMP a pesar de fallos de DF-Ping → PMTUD-Blackhole (a menudo por firewalls, NAT o túneles que bloquean ICMP).

Un extracto de tcpdump de ejemplo y su significado:

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)

Aquí la larga pausa y la retransmisión posterior indican pérdida o descarte de paquetes. Si en su lugar aparece un ICMP „Fragmentation Needed“, la causa es la fragmentación.

Comprobaciones de MTU: pasos concretos

Los problemas de MTU son muy frecuentes en entornos con encapsulamiento (VPN, WireGuard, VXLAN, GRE). Pasos de verificación:

1) Comprobar la MTU de la interfaz

ip link show

Tenga en cuenta interfaces de túnel/overlay como wg0, tun0, vxlan0 u otros dispositivos CNI (cni0, flannel.1). La MTU efectiva del camino = la MTU más pequeña menos la sobrecarga del encapsulamiento.

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

Si los DF-Pings grandes fallan, reduzca el tamaño de forma gradual hasta que lleguen respuestas — eso muestra la MTU real del camino.

3) MSS-Clamping como solución pragmática

Si ICMP está bloqueado en el trayecto (PMTUD-Blackhole), MSS-Clamping reduce la longitud de datos útiles negociada en el TCP-Handshake. Ejemplo 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 corrige solo TCP; los protocolos basados en UDP seguirán afectados. Aplique esta medida de forma focalizada en el borde del trayecto problemático y documentela en el Change-Log.

Kubernetes: notas especiales de verificación y operación

Los clústeres de Kubernetes suelen usar redes overlay (VXLAN, Geneve) o host-networks con dispositivos CNI. Estos generan cabeceras adicionales y reducen la MTU efectiva. Además, en muchas empresas la política de ICMP es RESTrictiva, lo que interfiere con PMTUD.

Práctica: comprobar MTU y tcpdump en un clúster

Distribuya la prueba mediante un DaemonSet o un Debug-Pod temporal en todos los nodos para asegurarse de que se verifica la ruta completa.

# 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

Alternativamente distribuya un DaemonSet con tcpdump, recopile los pcap de forma centralizada y compare nodo a nodo. Tenga en cuenta permisos y protección de datos: los PCAP pueden contener información sensible.

Monitorización, automatización y prevención

Para evitar incidentes recurrentes, se recomienda una combinación de monitorización y medidas preventivas:

• Medición de la latencia de inicio de sesión SSH: una comprobación sintética sencilla que abre periódicamente una conexión y mide el tiempo hasta el prompt. Ejemplo de script abajo.
• Health checks de red: comprobar regularmente la MTU del trayecto y la disponibilidad de ICMP.
• Alertas: si la latencia de inicio de sesión SSH > x segundos o aparecen retransmisiones/errores ICMP en tcpdump, abrir un ticket.
• Documentación: todos los workarounds temporales (MSS-Clamp, cambios de MTU, UseDNS) en el Change-Log y con un owner asignado.

Ejemplo de script para medición sintética de latencia SSH (BatchMode evita la entrada de contraseña):

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

Estrategia de reversión y seguridad

Todas las intervenciones deben ser reversibles y probadas. Reglas básicas:

• Comprobar los cambios en /etc/ssh/sshd_config con sshd -t y probarlos en una segunda sesión de administrador antes de cerrar las sesiones antiguas.
• Asegurar reglas de firewall e iptables con expiración o desplegarlas mediante gestión de configuración, de modo que sea posible un revert automático.

Escollos prácticos

Errores típicos que consumen tiempo:

• Capturas de tcpdump unilaterales: el enrutamiento asimétrico conduce a conclusiones erróneas. Siempre capturar en varios puntos.
• ICMP bloqueado en firewalls pero no documentado: PMTUD se rompe sin errores evidentes.
• AuthorizedKeysCommand sin timeout/cache: la caída de una API externa bloquea el inicio de sesión.
• Establecer MSS-Clamp de forma global sin documentación: problemas de rendimiento posteriores permanecen sin explicación.

Resumen / Conclusión

Con un análisis por fases, las conexiones SSH lentas se vuelven manejables: utilice ssh -vvv para identificar la fase afectada; tcpdump muestra indicadores de transporte y PMTUD; DF-Pings y comprobaciones de MTU proporcionan la MTU del camino. En entornos Kubernetes y VPN, MTU/PMTUD son especialmente relevantes, porque las encapsulaciones reducen el tamaño efectivo del paquete y los mensajes ICMP a menudo están bloqueados. Aplique workarounds pragmáticos y documentados (MSS-Clamping, ajuste temporal de MTU en túneles) y planifique en paralelo la corrección raíz (DNS-PTR, política de ICMP, estabilización de KDC/NTP). Un runbook breve y reproducible y comprobaciones sintéticas automatizadas evitan repeticiones y reducen el esfuerzo en incidentes.

Lista de comprobación para pruebas y runbook (versión corta)

• Documentar la reproducción (cliente, hora, ruta).
• Ejecutar ssh -vvv, anotar la fase.
• Probar con IP en lugar de nombre de host; desactivar temporalmente GSSAPI.
• Servidor: comprobar logs, sshd -T, AuthorizedKeysCommand/LDAP/SSSD-Timeouts.
• tcpdump en ambos extremos: filtro SSH + ICMP.
• Comprobar MTU: ip link, DF-Ping, MSS-Clamp solo después del análisis.
• En Kubernetes: comprobar la CNI-MTU en todos los nodos, usar Debug-Pods/DaemonSet.
• Documentar los cambios y diseñarlos con capacidad de rollback.

Perspectiva de arquitectura y operaciones: por qué las conexiones SSH lentas se vuelven sistémicas

Además de errores aislados, las conexiones SSH lentas suelen ser síntoma de inconsistencias arquitectónicas o operativas. Consideraciones que van más allá de las capturas de paquetes ayudan a planear soluciones duraderas: balanceadores de carga, pasarelas NAT, firewalls con estado, proveedores SD‑WAN y grupos de seguridad en la nube alteran el comportamiento de TCP/SYN, pueden eliminar ICMP o generar enrutamiento asimétrico. Documente la ruta completa (Cliente → Zonas → Bastión → Destino) y compruebe qué componentes terminan o actúan como proxy de TCP.

Comandos de comprobación para efectos en la infraestructura

Unas pocas comprobaciones simples suelen revelar influencias ocultas:

# Verificar funciones de offload (NIC/host VM)
ethtool -k eth0

# Flags del kernel para sondeo de MTU
sysctl net.ipv4.tcp_mtu_probing

# Carga de conntrack (relevante para NAT/firewalls)
sudo sysctl net.netfilter.nf_conntrack_count
sudo sysctl net.netfilter.nf_conntrack_max

Causas operativas típicas y riesgos

• Los offloads de NIC (GRO/LRO/TSO) pueden alterar el orden y el tamaño de los paquetes visibles; desactivarlos temporalmente para depuración, pero solo por poco tiempo — de lo contrario puede verse afectado el rendimiento.
• SYN‑Proxies o la terminación TCP en LB afectan el timing del handshake: compruebe si el proxy tiene timeouts adicionales.
• La agotación de conntrack detiene nuevas conexiones o aumenta retransmisiones; los cambios en nf_conntrack_max requieren planificación y monitorización.

Directrices operativas e integración

Planifique los cambios como pasos sencillos y reversibles: Canary‑Rollout (un Gateway), medición antes/después (SYN‑Latency, tcp_retrans) y automatización mediante gestión de configuración. Incluya scripts de verificación y la recolección de tcpdump en sus runbooks de CI/CD, para que la depuración sea reproducible y las responsabilidades estén claras. Preste atención a la protección de datos en los PCAPs y a propietarios explícitos para soluciones temporales como MSS‑Clamping o cambios en UseDNS.

En resumen: No considere las conexiones SSH lentas únicamente como un problema aislado, sino como un indicador de la arquitectura de red y operativa. Solo así se pueden implementar soluciones escalables, documentadas y reversibles.

Para este tema también son importantes Tcpdump Ssh y Mtu Check. El artículo contextualiza estos aspectos de forma comprensible y muestra en qué debe centrarse la práctica diaria.