PuTTY muestra Conexión rechazada: corrige la falla

En PuTTY, el mensaje « Error de red: Conexión rechazada » indica que la apertura de la conexión TCP ha sido rechazada. El cliente aún no ha llegado a la etapa de la contraseña o de la clave SSH. El rechazo puede provenir de la máquina objetivo, pero también de un firewall, una puerta de enlace o un redireccionamiento mal configurado: por lo tanto, este mensaje no prueba, por sí solo, que el servidor correcto ha respondido.

Proceda del cliente al servidor: anote el destino, verifique el puerto y luego controle la escucha y el filtrado desde una consola independiente. No reinicie el servidor ni modifique el firewall « para probar ». Si no tiene una consola de respaldo o un acceso ya abierto, deténgase antes de cualquier modificación en el lado del servidor y pida ayuda al administrador.

Confirme que se trata efectivamente de un rechazo TCP

Anote el texto exacto mostrado por PuTTY, la hora del intento y la sesión utilizada. En el menú de la ventana de PuTTY, abra el Registro de Eventos y anote el host, el puerto y la posible presencia de un proxy. Oculte los nombres internos y las direcciones antes de transmitir esta información. El manual de PuTTY distingue explícitamente Conexión rechazada de Tiempo de conexión agotado.

• Conexión rechazada: el intento TCP recibe un rechazo, a menudo un paquete RST. El rechazo puede ser emitido por el host o por un equipo intermedio configurado para rechazar.
• Tiempo de conexión agotado: no llega ninguna respuesta útil dentro del tiempo límite. Un filtrado silencioso de tipo DROP, una ruta, una dirección incorrecta o un equipo no disponible pueden conducir a este resultado. Este no es el mismo diagnóstico; el detalle del timeout se reserva para una guía separada.
• El servidor rechazó nuestra clave: la conexión SSH ha alcanzado la etapa de autenticación por clave, pero el servidor no acepta esta clave para esta cuenta. Verifique entonces los parámetros de la clave y la cuenta; consulte la guía para usar una clave SSH con PuTTY. Cambiar de clave no corregirá un rechazo TCP inicial.

Un ping no permite decidir: ICMP y el puerto TCP de SSH pueden ser filtrados de manera diferente. Un ping sin respuesta no demuestra por lo tanto que SSH esté caído, y un ping exitoso no valida el puerto SSH.

Verifique el host y el puerto en PuTTY

En PuTTY, cargue la sesión relevante y compare sus campos con la información proporcionada por el proveedor o el administrador: Nombre del host debe contener el nombre o la dirección, sin prefijo https://; el tipo de conexión debe ser SSH; el puerto debe ser el puerto SSH realmente publicado. No suponga que siempre se trata del puerto 22. Si corrige un valor, guarde la sesión solamente después de confirmar el destino correcto. Para los parámetros básicos de una sesión, consulte la guía verificar los parámetros de su sesión PuTTY.

Desde PowerShell de Windows, reemplace el nombre y el puerto de ejemplo por los de su sesión:

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

Resolve-DnsName muestra las direcciones asociadas con el nombre; compárelas con el destino esperado. Test-NetConnection prueba el puerto TCP indicado: TcpTestSucceeded : True significa que esta prueba ha establecido la conexión TCP, no que la identidad del servidor o la autenticación SSH están validadas. Un valor False no es suficiente para distinguir entre rechazo y tiempo agotado: conserve el mensaje exacto de PuTTY. Si PuTTY pasa por un proxy o un VPN, esta prueba directa puede seguir otro camino; los dos resultados no son entonces directamente comparables.

Desde un cliente Linux que tiene permiso para usar, también puede probar solo el puerto objetivo, si netcat está instalado:

nc -vz -w 3 servidor.ejemplo.net 22

Reemplace los dos valores. Las opciones -z y -v solicitan una prueba de conexión sin intercambio de aplicación y un resultado legible; -w 3 limita la espera a tres segundos. Las variantes de netcat difieren: si la opción no es reconocida, consulte nc -h y adáptese a la versión instalada, sin probar un rango de puertos. Una conexión establecida confirma el acceso TCP desde este cliente; un rechazo apoya la pista del rechazo; una espera expirada abre otra rama de diagnóstico. Consulte también la guía para probar un puerto TCP con netcat.

Controle el servicio desde una consola Linux

Este paso se realiza en la consola del proveedor, de la máquina virtual o frente al servidor, no en la sesión PuTTY que falla. Mantenga esta consola y cualquier sesión de administración ya abierta: son su medio de retorno si una modificación corta el acceso. El nombre de la unidad depende de la distribución y del modo de arranque.

systemctl list-unit-files 'ssh*' --no-pager
sudo systemctl status ssh.service --no-pager
sudo systemctl status sshd.service --no-pager
sudo systemctl status ssh.socket --no-pager

El primer comando inventaría las unidades cuyo nombre comienza por ssh. Luego, controle la unidad realmente presente: ssh.service es común en Debian y Ubuntu; sshd.service a menudo en Fedora y RHEL; algunos sistemas utilizan una activación por ssh.socket. « Unidad no encontrada » indica solo que este nombre de unidad no existe en esta máquina. Una unidad activa no prueba que el puerto solicitado escuche en la interfaz correcta. Con una activación por socket, systemd puede aceptar la conexión y arrancar el servicio a demanda. En un sistema sin systemd, use las herramientas de su distribución en lugar de transponer estos comandos.

Si no se ha instalado ningún servidor SSH, confirme primero con el administrador que esta máquina debe efectivamente proporcionar SSH. Instalar un paquete de servidor solo está justificado en este caso y de acuerdo a la procedimiento de la distribución; no es una reparación universal de un puerto incorrecto o de un rechazo de red.

Verifique el puerto y la dirección de escucha efectiva

Siempre desde la consola Linux, observe las interfaces, los sockets TCP en escucha y la configuración SSH:

ip -br address
sudo ss -ltnp
sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T

ip -br address muestra las direcciones locales; un servidor detrás de un NAT generalmente no muestra su dirección pública. En ss -ltnp, -l limita la visualización a los sockets en escucha, -t a TCP, -n mantiene los puertos numéricos y -p indica el proceso cuando está disponible. Localice el puerto esperado y el proceso propietario, que puede ser systemd si el socket está activado.

Interprete la dirección tanto como el puerto. Una escucha en 127.0.0.1:22 está limitada al bucle local; una dirección LAN específica no cubre otras interfaces. 0.0.0.0 designa todas las interfaces IPv4; una escucha en [::] se refiere a IPv6 y no garantiza por sí sola el acceso IPv4. Si no hay nada escuchando en el puerto al que llega el tráfico, no comience por abrir el firewall: no hay entonces ningún servicio en este destino.

sshd -t verifica la sintaxis y las claves de host sin iniciar ni reiniciar el servicio. Una ejecución válida normalmente no produce ningún mensaje y devuelve un código de éxito; un mensaje de error debe ser corregido antes de cualquier acción sobre el servicio. sshd -T muestra la configuración efectiva después de la lectura y validación, incluyendo los valores de puerto y dirección de escucha. No difunda su salida completa sin revisarla y ocultar detalles sensibles. El manual oficial describe las opciones sshd(8) y las directivas Puerto y ListenAddress. Estas páginas documentan OpenSSH; las rutas y unidades varían según Linux. En una configuración que utiliza ssh.socket, confronte también los resultados de ss a la unidad activa: la salida de sshd -T sola no prueba lo que el socket de systemd expone realmente.

No modifique Port o ListenAddress sino después de haber identificado una mala configuración y respaldado la configuración concernida. Confirme qué interfaz debe ser accesible; no amplíe la escucha a todas las interfaces por defecto. Antes de cualquier modificación o recarga, mantenga la consola de respaldo y el acceso existente abiertos. Ubuntu recuerda las precauciones relacionadas con la configuración del servidor en su documentación de OpenSSH Server.

Compare el filtrado local, la red y el NAT

Si el puerto escucha en la interfaz correcta pero la prueba externa es rechazada, identifique primero el gestor de firewall realmente utilizado y el camino del tráfico. Los comandos a continuación son de solo lectura: ejecute solo el que corresponda a su sistema.

sudo ufw status verbose
sudo nft list ruleset
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

UFW, nftables y firewalld no son intercambiables. Un comando ausente no prueba que no haya ningún filtrado. Con firewalld, public es solo un ejemplo de zona: identifique la zona asociada a la interfaz, luego examine las reglas, su orden, el protocolo TCP, el puerto, las fuentes autorizadas y las acciones de rechazo. No combine múltiples gestores para aplicar cambios y no desactive el firewall para probar.

Verifique luego, de solo lectura, las reglas del firewall en la nube o del proveedor: puerto publicado, protocolo y direcciones fuente autorizadas. Si el servidor está detrás de un enrutador, controle el redireccionamiento del puerto externo a la dirección privada correcta y al puerto que realmente está en escucha. Por ejemplo, un redireccionamiento conceptual del puerto externo 2222 al puerto interno 22 implica que PuTTY se conecta al puerto 2222 desde Internet, mientras que ss muestra el puerto 22 en el servidor. Verifique también que la dirección privada de la máquina no ha cambiado. Si se prevé un VPN o un bastión, favorezca este camino en lugar de exponer SSH a toda Internet.

Una prueba desde la misma red local hacia la dirección pública depende del soporte de NAT loopback por el router; no reemplaza una prueba exterior autorizada. La falta de respuesta relacionada con el enrutamiento, a una dirección pública o a CGNAT a menudo conduce a la rama del timeout: no intente eludirla abriendo puertos sin validación.

Aplique una sola corrección probada, luego reteste

• Host o puerto erróneo en la sesión: corrija únicamente el destino del cliente confirmado por el administrador.
• Servicio ausente cuando SSH debe ser proporcionado: haga validar la instalación y la activación de acuerdo con la distribución.
• Servicio detenido, configuración válida, unidad correcta y acceso a la consola asegurado: un arranque controlado puede ser apropiado.
• Dirección de escucha incorrecta: corrija solamente el bind confirmado y verifique primero la configuración.
• Regla de rechazo demostrada: solicite o aplique una regla limitada al puerto SSH, al protocolo y a las fuentes necesarias.
• Redireccionamiento erróneo: corrija la dirección privada o el puerto externo después de confirmar el trayecto esperado.

Para un servicio systemd realmente detenido, únicamente si el servidor debe proporcionar SSH, si sshd -t ha tenido éxito, si la unidad es efectivamente la utilizada y si la consola de respaldo es accesible, el arranque controlado puede ser:

sudo systemctl start ssh.service

Reemplace ssh.service por sshd.service si es la unidad presente; no inicie ambos y no arranque un servicio en competencia con un socket de activación. Este comando cambia el estado de la máquina: no debe usarse como primera prueba. Después de una modificación de configuración, verifique primero el mecanismo de recarga soportado por su distribución y su unidad; no se recomienda ningún reinicio automático aquí. La documentación oficial de Ubuntu recuerda que una modificación SSH puede bloquear el acceso: mantenga abierta la sesión y la consola de respaldo durante el control.

Después de cada corrección, proceda por separado: revise ss -ltnp en el lado del servidor, luego abra una nueva ventana PuTTY hacia el host y el puerto corregidos. Si PuTTY presenta una nueva huella de host, verifíquela por un canal confiable antes de aceptarla. Alcanzar el banner de SSH o la pantalla de autenticación significa que el rechazo TCP ha sido levantado; esto no significa que la cuenta ya esté autenticada. Mantenga el acceso de respaldo mientras esta nueva conexión no ha sido exitosa.

No use ufw disable, nft flush ruleset o iptables -F. No abra SSH globalmente sin restricción de origen, no eluda el problema activando la conexión root y no debilite ni las permisos SSH ni la autenticación multifactor.

Consulte los registros si el rechazo persiste

Desde la consola Linux, elija la unidad realmente presente y examine una ventana reciente alrededor de la hora anotada en PuTTY:

sudo journalctl -u ssh.service -n 50 --no-pager
sudo journalctl -u sshd.service -n 50 --no-pager
sudo journalctl -u ssh.socket -n 50 --no-pager

Ejecute solo el comando correspondiente a la unidad existente. Busque un error de configuración, una dirección no disponible o un puerto ya ocupado. Según la distribución y su registro, archivos como /var/log/auth.log o /var/log/secure pueden complementar el registro; no están presentes en todas partes. Un rechazo antes del establecimiento de SSH puede no dejar ninguna entrada de autenticación. De igual manera, un rechazo por un router o un firewall en la nube puede no aparecer en journalctl: la ausencia de línea no prueba la ausencia de intento.

Si usted es el administrador del servidor y tiene tcpdump, una captura muy corta puede ayudar a localizar el rechazo. Reemplace la dirección de documentación por la dirección fuente efectivamente vista en el servidor, que puede diferir después de NAT; no capture más que en una máquina y una red que usted está autorizado a diagnosticar.

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

timeout 10 limita la captura a diez segundos; -c 20 la detiene después de un máximo de veinte paquetes; -n evita la resolución de nombres y -i any escucha las interfaces disponibles. El ejemplo apunta al puerto interno 22: adapte el filtro al puerto observado. Un SYN entrante seguido de un RST en este punto de captura refuerza un rechazo en ese lugar, sin identificar automáticamente el equipo responsable. Ningún paquete capturado también puede resultar de una mala interfaz, un mal filtro o un camino de red diferente. No capture el contenido con opciones de decodificación de carga útil, no mantenga un archivo de captura permanente y oculte las direcciones y horarios antes de compartir los resultados.

Si no tiene consola independiente ni autorización para inspeccionar el firewall, no continúe las modificaciones a distancia. Transmita al administrador el host y el puerto objetivo, la hora, el mensaje exacto de PuTTY y las pruebas realizadas, después de haber expurgado la información interna.