Problema

En entornos con múltiples servidores y subredes, es frecuente que el cliente SSH logre establecer la conexión TCP (el banner “Connection established” aparece) y luego se quede esperando sin mostrar la solicitud de contraseña ni ningún mensaje de error. El proceso parece colgar en el primer intercambio de datos después del handshake. El síntoma típico es:

debug1: Connecting to 10.x.x.x [10.x.x.x] port 22.
debug1: Connection established.
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4

y nada más. La sesión funciona desde otras máquinas, pero falla de forma consistente desde un host específico (por ejemplo, un jump server). La causa rara vez está en el daemon SSH; suele estar en la capa de red que impide que el paquete de banner del cliente llegue al servidor o que la respuesta del servidor regrese al cliente.

Causa

1. Ruta asimétrica o tabla de rutas incompleta

Cuando el tráfico de salida y el de retorno siguen caminos diferentes, un firewall o un dispositivo de NAT puede descartar paquetes porque no coinciden con una regla esperada. En la práctica, el cliente envía el banner, el servidor lo recibe, pero la respuesta viaja por una ruta que el firewall no permite, provocando retransmisiones sin respuesta.

2. ACLs o reglas de firewall que filtran paquetes SSH de origen específico

Muchas organizaciones aplican listas de control de acceso basadas en IP de origen, zona de seguridad o etiqueta de interfaz. Si la regla permite tráfico entrante a 22 TCP pero no permite tráfico saliente hacia la IP del jump server, el cliente nunca verá la respuesta del servidor.

3. MTU y fragmentación de paquetes

SSH usa paquetes relativamente pequeños, pero el banner inicial y la negociación de algoritmos pueden generar paquetes que superen la MTU de la ruta si hay túneles VPN o encapsulaciones. Un MTU sub‑optimizado causa que los paquetes se fragmenten y, si alguna pieza se pierde, la conexión queda a la espera.

4. Configuración errónea de la interfaz de red del servidor

Si la interfaz que escucha en 0.0.0.0 tiene una dirección IP secundaria o una subred mal configurada, el daemon puede aceptar la conexión TCP pero enviar la respuesta por una interfaz equivocada, resultando en pérdida de paquetes.

5. Problemas de NAT estático o dinámico

En entornos cloud, los servidores pueden estar detrás de un NAT de capa 3. Un mapeo NAT mal definido permite la llegada del SYN, pero la respuesta SYN‑ACK se traduce a una IP que no coincide con la del cliente, provocando que el cliente retransmita sin éxito.

Solución

Paso 1 – Verificar la ruta de ida y vuelta

Ejecuta traceroute desde el jump server hacia el objetivo y, si es posible, desde el objetivo hacia el jump server. Las rutas deben converger en el mismo punto de salida. Si notas diferencias, revisa la tabla de rutas estáticas o los protocolos de routing (OSPF, BGP) en los routers intermedios.

Paso 2 – Capturar tráfico con tcpdump en ambos extremos

En el jump server:

tcpdump -i any -nn host 10.x.x.x and port 22 -vv

En el servidor objetivo:

tcpdump -i any -nn host <IP_JUMP> and port 22 -vv

Busca el paquete SYN del cliente, el SYN‑ACK del servidor y el paquete de banner del cliente (SSH-2.0). Si el banner llega al servidor pero no ves respuesta del servidor en la captura del cliente, el problema está en la ruta de retorno o en un filtro.

Paso 3 – Revisar ACLs y reglas de firewall

En los firewalls de perímetro y en los security groups del cloud, confirma que exista una regla que permita tráfico bidireccional TCP/22 entre las subredes involucradas. Asegúrate de que la regla no esté limitada a un puerto de origen o a un rango de IP que excluya al jump server.

Paso 4 – Probar con MTU reducido

Desde el jump server, fuerza un ping sin fragmentación:

ping -M do -s 1472 10.x.x.x

Si se pierden paquetes, reduce la MTU en la interfaz del jump server (por ejemplo, a 1400) y vuelve a intentar la conexión SSH. En Linux, modifica temporalmente:

ip link set dev eth0 mtu 1400

Si la conexión funciona con MTU menor, el problema está en la fragmentación; ajusta la MTU de la ruta o habilita MSSClamping en los dispositivos de NAT.

Paso 5 – Verificar la configuración de la interfaz del servidor

Ejecuta ip addr show y ip route en el servidor objetivo. Asegúrate de que la dirección IP que responde al SYN‑ACK sea la misma que el cliente utilizó para conectar. Si existen direcciones secundarias, prueba deshabilitarlas temporalmente o forzar la escucha en la IP correcta con ListenAddress en /etc/ssh/sshd_config.

Paso 6 – Eliminar NAT problemático

Si el servidor está detrás de un NAT, verifica la tabla de traducción. En entornos cloud, revisa los “public IP” y los “private IP” asociados al recurso. Asegúrate de que el mapeo sea 1‑a‑1 para la IP del servidor y que el security group permita el tráfico de retorno.

Paso 7 – Reiniciar servicios de red y SSH (solo si los cambios son menores)

Después de ajustar rutas o reglas, recarga la configuración:

systemctl restart sshd
ip route flush cache

Cuándo aplicar esta solución

  • Síntomas: el cliente muestra “Connection established” y luego se queda bloqueado sin solicitar contraseña ni error; la misma IP funciona desde otras máquinas.
  • Entorno: múltiples subredes, uso de jump servers, firewalls basados en ACL, NAT o VPN.
  • No aplica: cuando el cliente nunca llega a la fase de handshake (no se ve SYN en tcpdump) o cuando el daemon SSH está caído (puerto 22 cerrado).

Código

# Paso 1: traceroute bidireccional
traceroute -n 10.x.x.x
ssh <user>@10.x.x.x "traceroute -n $(hostname -I | awk '{print $1}')"

# Paso 2: capturas tcpdump simultáneas
# En jump server
tcpdump -i any -nn host 10.x.x.x and port 22 -c 20 -w /tmp/jump.pcap
# En servidor objetivo
tcpdump -i any -nn host <IP_JUMP> and port 22 -c 20 -w /tmp/server.pcap

# Paso 4: prueba de MTU
ping -M do -s 1472 10.x.x.x
ip link set dev eth0 mtu 1400   # ajustar si es necesario

Verificación

  1. Conexión exitosa: ssh -vvv user@10.x.x.x debe avanzar más allá del banner y solicitar autenticación.
  2. Capturas: revisa los archivos .pcap con Wireshark; deberías ver el flujo SYN → SYN‑ACK → ACK → banner → respuesta del servidor.
  3. Ping sin fragmentación: sin pérdida de paquetes al usar el tamaño MTU final.
  4. Reglas de firewall: confirma que la regla de permiso bidireccional sigue activa (iptables -L -v -n o equivalente en el cloud).

Notas adicionales

  • En entornos con IPsec o GRE tunnels, la MTU suele reducirse automáticamente; verifica la configuración del túnel antes de forzar valores manuales.
  • Algunos proveedores de cloud añaden security groups implícitos que bloquean el tráfico de retorno; revisa tanto el security group del servidor como el del jump server.
  • Si la causa resulta ser una ruta asimétrica, considera habilitar ECMP o policy routing para forzar que ambos sentidos usen la misma salida.
  • Mantén los logs de sshd en DEBUG (LogLevel DEBUG) solo mientras diagnosticas; el nivel alto genera mucho ruido y puede afectar el rendimiento.