PuTTY muestra Tiempo de conexión agotado: encontrar la causa

¿PuTTY muestra Error de red: se ha agotado el tiempo de conexión? Al abrir la sesión, esto significa que no se ha recibido ninguna respuesta útil dentro del tiempo esperado. La dirección o el puerto pueden ser incorrectos, la ruta de red puede ser inaccesible o asimétrica, o un equipo puede estar dejando los paquetes sin respuesta. En este punto, la contraseña y la clave SSH aún no son un problema.

Un rechazo de conexión es diferente: la conexión TCP ha sido rechazada, por ejemplo, por un puerto sin servicio escuchando o por un equipo intermedio. Este rechazo no prueba por sí solo que el servidor correcto haya respondido. Para esta otra rama, consulte el diagnóstico de Connection refused en PuTTY. El manual describe oficialmente el timeout de PuTTY como la ausencia de respuesta del servidor y menciona, en particular, un servidor aislado o apagado y una dirección a verificar. También señala que un timeout puede ocurrir después de una pérdida de contacto durante una conexión: esta guía se centra en la apertura de la sesión.

Proceda sin modificar el servidor a ciegas: verifique primero el destino y la ruta desde Windows, luego compare estas observaciones con la escucha, la ruta de regreso y el filtrado del lado de Linux. Para los comandos del servidor, use una consola independiente proporcionada por el proveedor, la VM o el acceso físico. Mantenga cualquier sesión SSH ya abierta.

Identificar el timeout antes de cambiar cualquier cosa

Anote el texto exacto mostrado por PuTTY, la hora con el huso horario, la sesión utilizada, el nombre de host, el puerto y el paso donde ocurre la falla. También registre si está pasando por un proxy configurado en PuTTY, un VPN o un bastión. Los detalles disponibles en el Event Log de PuTTY pueden ayudar a confirmar la ruta y la dirección intentadas.

• Timeout al abrir: no se ha recibido ninguna respuesta útil dentro del tiempo. Esto indica hacia la dirección, el enrutamiento o un filtrado silencioso, sin distinguir entre estas causas.
• Connection refused: la ruta ha recibido un rechazo TCP. Verifique la rama dedicada a el rechazo de conexión.
• Server refused our key: el transporte ha llegado a la etapa de autenticación; esta es otra falla. Puede entonces consultar la guía sobre el uso de una clave SSH con PuTTY.
• Una sesión establecida se corta después de un período de inactividad: este no es el mismo caso que un timeout al abrir. No cuente con un ajuste keepalive para reparar una ruta TCP inicial que no responde.

No busque una duración universal para ajustar en PuTTY: alargar la espera no repara una ruta ausente ni un paquete filtrado.

Verificar la dirección, el DNS y el puerto realmente publicado

Abrir la sesión guardada en PuTTY y controle el host y el puerto en los parámetros SSH. El campo host contiene un nombre o una dirección, no una URL con https://. Confirme estos valores con el administrador o en la consola del proveedor antes de reemplazarlos. Para revisar los campos de una sesión, consulte los parámetros de una sesión SSH en PuTTY.

En PowerShell, reemplace servidor.ejemplo.net por el nombre validado y 22 por el puerto TCP externo realmente publicado para su acceso. Estos valores son ejemplos, no los parámetros de su servidor.

Resolve-DnsName servidor.ejemplo.net -Type A
Resolve-DnsName servidor.ejemplo.net -Type AAAA
Test-NetConnection -ComputerName servidor.ejemplo.net -Port 22 -InformationLevel Detailed

Los dos primeros comandos mostrarán por separado las direcciones IPv4 (A) y IPv6 (AAAA) obtenidas por resolución DNS. Compare la dirección devuelta con la esperada en la consola del proveedor. Un registro AAAA puede hacer que PuTTY adopte un camino IPv6 diferente del camino IPv4. La documentación de Microsoft de Test-NetConnection detalla el resultado TCP y el diagnóstico de ruta.

En el resultado detallado de Test-NetConnection, anote especialmente RemoteAddress, SourceAddress, InterfaceAlias y TcpTestSucceeded. Puede probar por separado una dirección ya validada para distinguir un problema de resolución de una falla TCP. No use una dirección encontrada al azar y no acepte una nueva huella de clave de host sin verificarla por un canal fiable.

• TcpTestSucceeded : True significa que esta prueba ha establecido TCP hacia este destino, este puerto y este camino, en este momento. Esto no verifica la identidad SSH del servidor. Si PuTTY aún falla, compare la dirección y el puerto utilizados, su posible proxy y los parámetros de la sesión.
• TcpTestSucceeded : False indica un fallo de la prueba TCP, pero no distingue por sí solo un timeout de un rechazo ni localiza la pérdida. Conserve el mensaje exacto de PuTTY y continúe con las verificaciones.

Una dirección privada generalmente solo es accesible desde la red prevista o un VPN con la ruta correcta. En caso de NAT, el puerto utilizado por el cliente puede diferir del puerto interno escuchando: por ejemplo, un puerto externo conceptual 2222 puede ser redirigido al puerto interno 22. Haga confirmar la coincidencia; no reemplace estos ejemplos por valores supuestos. No limpie el caché DNS por reflejo: hágalo solo si se ha demostrado una entrada local obsoleta.

Comparar las rutas de Windows, VPN y red

Verifique la red activa, el acceso al VPN o al bastión esperado, las rutas y la dirección fuente utilizada. Si PuTTY pasa por un proxy, una prueba directa de PowerShell no valida este proxy: las dos pruebas no necesariamente toman el mismo camino.

Los siguientes comandos son lecturas del lado de Windows. Para tracert, reemplace 192.0.2.20 por la dirección de un servidor que tiene permiso para probar. 192.0.2.20 es una dirección reservada para ejemplos de documentación, no la dirección real de su servidor.

ipconfig
route print
Test-NetConnection -ComputerName servidor.ejemplo.net -DiagnoseRouting -InformationLevel Detailed
tracert -d 192.0.2.20

ipconfig y route print ayudan a registrar las interfaces y rutas locales. -DiagnoseRouting solicita un diagnóstico de ruta; esto es un conjunto de parámetros distinto de la prueba con -Port, no combine ambos en el mismo comando. tracert muestra pasos de recorrido, pero asteriscos pueden simplemente señalar que no se están devolviendo respuestas ICMP. No designan con certeza el equipo que bloquea SSH. Del mismo modo, un ping exitoso no prueba que SSH sea accesible, y un ping fallido no prueba que el servidor esté apagado.

Si está permitido, compare el mismo host y el mismo puerto desde otra red, con los otros parámetros sin cambios. Un éxito a través de un hotspot, por ejemplo, indica una diferencia de camino, de origen o de permisos en la primera red; esto no prueba automáticamente que el proveedor de acceso esté bloqueando el puerto 22. Una lista de direcciones de origen permitidas puede explicar esta diferencia. Verifique las reglas salientes de Windows y las políticas de red con el administrador. No desactive ni cortafuegos ni antivirus y no evite una política de red.

Controlar la escucha y la ruta de regreso desde Linux

Ejecútese estas lecturas desde la consola independiente del servidor, y no en la ventana PuTTY en falla. Reemplace 192.0.2.10 por la dirección fuente que el servidor ve realmente, tras NAT o VPN. 192.0.2.10 es una dirección de documentación a reemplazar, no una IP real de cliente. Para una destino IPv6, use ip -6 route get con la dirección IPv6 observada.

ip -br address
ip route
ip route get 192.0.2.10
sudo ss -ltnp
systemctl list-unit-files 'ssh*' --no-pager
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

ip -br address resume las direcciones de las interfaces; ip route muestra las rutas IPv4 y ip route get indica el camino elegido hacia la fuente que se integrará de regreso. Compare este camino con el recorrido real: la presencia de una ruta por defecto no prueba que la respuesta llegue al cliente. En una distribución donde el binario no esté en /usr/sbin/sshd, adapte su ruta conocida en lugar de concluir su ausencia.

ss -ltnp muestra los sockets TCP en escucha y, dependiendo de los privilegios, el proceso asociado. Verifique el puerto interno y la dirección de escucha: una escucha limitada a 127.0.0.1 no es accesible desde el exterior. Una escucha en [::] no garantiza por sí sola una accesibilidad IPv4. La dirección pública de un servidor detrás de NAT no aparece necesariamente en sus interfaces de Linux.

Identifique la unidad realmente utilizada antes de consultar su estado. Según la distribución, puede llamarse ssh.service o sshd.service; la activación por socket puede usar ssh.socket. Una unidad desconocida no significa necesariamente que SSH esté ausente. Controle únicamente la unidad identificada, por ejemplo:

systemctl status ssh.service --no-pager

Reemplace ssh.service por la unidad existente. El manual de OpenSSH para sshd describe -t como un control de configuración y coherencia de claves, y -T como la exhibición de la configuración efectiva. Estas opciones no reinician el servicio. Las reglas Match pueden depender de los parámetros de conexión; -T solo no prueba la configuración aplicable a cada cliente. Con una activación por socket, observe también la escucha real con ss y la unidad de socket.

Las directivas ListenAddress y Port determinan direcciones y puertos de escucha en la configuración; no garantizan ni enrutamiento, ni regla de cortafuegos, ni publicación del puerto por el NAT. Un puerto sin escucha produce a menudo un rechazo si el paquete alcanza el host sin filtrado silencioso: no concluya, por tanto, que cualquier timeout significa que el servicio SSH está detenido.

Localizar el filtrado sin abrir SSH a todo Internet

Identifique el cortafuegos realmente utilizado antes de interpretar sus reglas. Estos comandos son lecturas y pueden no estar todos disponibles en su distribución:

sudo ufw status verbose
sudo nft list ruleset
sudo firewall-cmd --get-active-zones

Si firewalld está activo, consulte luego la zona realmente asociada a la interfaz, reemplazando ZONE por su nombre:

sudo firewall-cmd --zone=ZONE --list-all

Un comando ausente no demuestra que no exista filtrado: una regla puede encontrarse en otro gestor, en un router o en el proveedor. No combine gestores de cortafuegos tratando de reparar la falla.

Para la regla correspondiente al camino observado, verifique el protocolo TCP, el puerto interno, la dirección fuente vista por el servidor, el orden de las reglas y la acción. Una regla DROP puede dejar la conexión sin respuesta; un REJECT puede provocar un rechazo según la forma del rechazo. Examine también los grupos de seguridad o cortafuegos en la nube, la ruta del proveedor, el router, la redirección NAT, el VPN y un posible CGNAT. Una prueba de la dirección pública desde el LAN depende, entre otros, de la compatibilidad con el NAT loopback; una redirección no funciona necesariamente detrás de un CGNAT.

No corrija más de una regla o ruta identificada por las observaciones, limitando la fuente a las direcciones necesarias. No abra el puerto a 0.0.0.0/0 por defecto y no mueva SSH al puerto 443 como un contorno automático.

Cruzar los registros y una captura TCP corta

Consulte los registros alrededor de la hora anotada, ajustando la unidad a la realmente utilizada:

sudo journalctl -u ssh.service --since '10 minutes ago' --no-pager

Reemplace ssh.service por la unidad existente, por ejemplo sshd.service o, según el caso, ssh.socket. Algunas distribuciones también registran eventos en /var/log/auth.log o /var/log/secure. Un timeout ocurrido antes del intercambio SSH puede no dejar ninguna línea de autenticación: un registro vacío no demuestra la ausencia de intentos.

Si tcpdump y GNU timeout están disponibles y está autorizado a capturar, reemplace el puerto y la dirección por el puerto interno y la fuente realmente vistas por el servidor. Inicie la captura justo antes de un nuevo intento de PuTTY:

sudo timeout 10 tcpdump -ni any -c 20 'tcp port 22 and host 192.0.2.10'

En este comando, el puerto 22 y 192.0.2.10 son ejemplos documentales a reemplazar por los valores observados, no datos de su falla. La captura se detiene después de diez segundos o tras veinte paquetes. No use las opciones -A o -X y no deje en marcha una captura permanente. Oculte las direcciones antes de compartir una salida.

• Ningún SYN en el punto observado: después de haber verificado la interfaz, el filtro de captura, la hora y la dirección fuente, examine el destino, la ruta o un filtrado aguas arriba. Esto no prueba por sí solo que un cortafuegos en la nube bloquee el tráfico.
• SYN recibido, ninguna respuesta observada: verifique el filtrado local, la escucha y las condiciones de captura. No acuse a sshd sin otra prueba.
• SYN recibido luego SYN-ACK emitido, pero ningún ACK final visible: examine el camino de regreso o un filtrado del lado del cliente/intermedio. Una captura del lado del servidor sola no localiza definitivamente la pérdida.
• SYN seguido de un RST: está en la rama del rechazo TCP; consulte el diagnóstico dedicado a Connection refused.
• Intercambio TCP completo: TCP ha funcionado en ese instante. Compare la captura con el intento de PuTTY, con el proxy y con la etapa SSH alcanzada. Esto no prueba ni la identidad del servidor ni una autenticación exitosa.

Corregir una causa probada y validar sin cortar SSH

Antes de realizar cualquier modificación, respalde el archivo relevante y asegúrese de tener una consola de respaldo. Proceda a una sola modificación a la vez: corrija el destino de la sesión, la ruta VPN o la regla específica que las pruebas han cuestionado. Si no tiene una consola independiente, detenga los cambios a distancia y envíe los resultados al administrador.

No modifique las claves, las contraseñas, PermitRootLogin o los algoritmos SSH para reparar un silencio de red antes de la autenticación. Si cambia la configuración SSH, haga primero que sshd -t tenga éxito, luego use la recarga soportada por la unidad y la distribución, después de haber verificado su funcionamiento. Un reinicio o un reboot no es una primera prueba y una recarga no necesariamente corrige un socket de systemd mal expuesto.

Nunca ejecute ufw disable, nft flush ruleset o iptables -F. No detenga Fail2ban a ciegas, no abra SSH a todas las fuentes y no cierre la sesión antigua antes de validar.

Después de una corrección, mantenga la consola y la sesión antigua abiertas. En una nueva ventana de PuTTY, vuelva a probar el mismo host, el mismo puerto y el mismo camino. Verifique la huella SSH por un canal fiable, continúe hasta la autenticación y luego confirme que una sesión funciona. Si el mensaje se convierte en Connection refused, regrese a esta rama en lugar de continuar diagnosticando el timeout.

Para solicitar ayuda, comunique la hora, el host y el puerto, las direcciones resueltas y la dirección fuente, el camino VPN/proxy, los resultados TCP y la observación del lado del servidor, así como la regla sospechosa. Expurgue las direcciones e información sensible. No presente una salida de comando no ejecutada como un resultado.