Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Solucionar errores de conexión SSH denegada rápidamente

Encontrarse con un error de "Conexión denegada" de SSH puede detener la gestión de su servidor remoto. Esta guía completa detalla la solución de problemas paso a paso, centrándose en diagnósticos críticos del lado del servidor. Aprenda a verificar el estado de su demonio SSH, comprobar y configurar las reglas del firewall (UFW, firewalld), inspeccionar la configuración de `sshd_config` y utilizar pruebas básicas de conectividad de red. Se proporcionan comandos prácticos y consejos prácticos para resolver rápidamente el problema y restaurar el acceso seguro a sus sistemas, asegurando que vuelva a tener el control rápidamente.

50 vistas

Solucionar errores de conexión SSH rechazada rápidamente

SSH (Secure Shell) es la columna vertebral de la gestión de servidores remotos, permitiendo una comunicación segura y cifrada entre tu máquina local y un servidor remoto. Sin embargo, encontrarse con un error ssh: connect to host <IP_ADDRESS> port 22: Connection refused puede ser un obstáculo frustrante, impidiéndote acceder a tus sistemas cruciales.

Este artículo proporciona una guía completa y paso a paso para diagnosticar y resolver el error común 'Connection Refused' (Conexión rechazada). Exploraremos los principales culpables, desde demonios SSH inactivos hasta firewalls mal configurados y configuraciones de servidor incorrectas, equipándote con el conocimiento y los comandos para recuperar rápidamente el acceso a tus servidores.

Entendiendo el error 'Connection Refused'

Cuando recibes un error de Connection refused (Conexión rechazada), significa que tu cliente SSH alcanzó el servidor remoto con éxito, pero el servidor denegó explícitamente la conexión en el puerto especificado. Esto es distinto de un error de Connection timed out (Conexión agotada) (donde el cliente no pudo alcanzar el servidor en absoluto) o un error de No route to host (No hay ruta al host) (donde la ruta de red está rota).

El estado "rechazado" apunta directamente a un problema en el lado del servidor que está impidiendo activamente que el servicio SSH acepte conexiones. Esto típicamente implica que el demonio SSH no está en ejecución, un firewall bloqueando la conexión o una configuración errónea dentro del propio servicio SSH.

Causas comunes de 'Connection Refused'

Varios factores pueden llevar a que una conexión SSH sea rechazada. Comprenderlos ayuda a reducir el proceso de solución de problemas:

  • Demonio SSH (sshd) no en ejecución: La causa más común. El proceso del servidor SSH podría haberse caído, detenido o no haber logrado iniciarse al arrancar.
  • Firewall bloqueando el puerto 22 (o un puerto personalizado): El firewall del servidor (por ejemplo, UFW, firewalld, iptables) está impidiendo las conexiones entrantes en el puerto SSH.
  • Configuración incorrecta del demonio SSH: El archivo sshd_config podría estar mal configurado, lo que lleva al demonio SSH a escuchar en un puerto diferente, una interfaz de red incorrecta, o a rechazar conexiones para usuarios/métodos específicos.
  • Problemas de conectividad de red (menos común para 'Rechazado'): Aunque es menos probable para un error "rechazado", un problema de red fundamental podría manifestarse a veces inesperadamente.
  • Restricciones de SELinux o AppArmor: Mejoras de seguridad como SELinux o AppArmor podrían estar impidiendo que sshd funcione correctamente, especialmente después de configuraciones personalizadas o cambios en el sistema.

Guía de solución de problemas paso a paso

Profundicemos en los pasos prácticos para diagnosticar y solucionar el error 'Connection Refused'.

Paso 1: Verificar el estado del demonio SSH en el servidor

Lo primero que hay que comprobar es si el demonio del servidor SSH (sshd) está realmente en ejecución en tu máquina remota. Típicamente necesitarás acceso a la consola (por ejemplo, a través de la consola de un proveedor de nube o una conexión física) para realizar estas comprobaciones si SSH es completamente inaccesible.

  1. Verificar el estado del demonio SSH:
    En la mayoría de las distribuciones modernas de Linux (las que usan systemd como Ubuntu, CentOS 7+, Debian 8+):
    bash sudo systemctl status sshd
    Si sshd no está en ejecución, la salida indicará inactive (dead) o un estado similar.

  2. Iniciar el demonio SSH:
    Si el estado es inactivo, intenta iniciar el servicio:
    bash sudo systemctl start sshd

  3. Habilitar el demonio SSH para que inicie al arrancar:
    Para asegurar que SSH se inicie automáticamente después de un reinicio, habilítalo:
    bash sudo systemctl enable sshd

  4. Verificar los registros del demonio SSH:
    Si sshd no se inicia, sus registros pueden proporcionar pistas cruciales. Para sistemas systemd:
    bash sudo journalctl -u sshd --since "10 minutes ago"
    Alternativamente, verifica los registros generales de autenticación:
    bash sudo tail -f /var/log/auth.log # O para RHEL/CentOS: sudo tail -f /var/log/secure

Paso 2: Verificar las reglas del firewall

Un firewall en el lado del servidor suele ser el culpable de los rechazos de conexión. Podría estar bloqueando el puerto SSH predeterminado (22) o un puerto personalizado que estás intentando usar. Debes asegurarte de que el firewall permita las conexiones entrantes en el puerto SSH.

  1. Identificar tu firewall:
    Los firewalls comunes incluyen:

    • UFW (Uncomplicated Firewall): Común en Ubuntu/Debian.
    • firewalld: Común en CentOS/RHEL 7+.
    • iptables: El firewall subyacente para Linux, configurado directamente o a través de interfaces.

  2. Verificar el estado y las reglas del firewall:

    • UFW:
      bash sudo ufw status verbose
      Busca reglas que permitan el tráfico en el puerto 22 (o tu puerto SSH personalizado). Si SSH aparece en la lista, asegúrate de que esté ALLOWed (permitido).
    • firewalld:
      bash sudo firewall-cmd --list-all
      Verifica las secciones services y ports para ssh o port 22/tcp.
    • iptables:
      bash sudo iptables -L -v -n
      Esta salida puede ser compleja. Busca reglas DROP o REJECT relacionadas con tcp dpt:22 (o tu puerto personalizado) en la cadena INPUT.

  3. Permitir el puerto SSH a través del firewall:

    • UFW:
      bash sudo ufw allow ssh # Permite el puerto 22 # O, para un puerto personalizado (por ejemplo, 2222): sudo ufw allow 2222/tcp sudo ufw enable # Si UFW está inactivo
    • firewalld:
      bash sudo firewall-cmd --permanent --add-service=ssh # O, para un puerto personalizado (por ejemplo, 2222): sudo firewall-cmd --permanent --add-port=2222/tcp sudo firewall-cmd --reload
    • iptables:
      Añadir reglas de iptables directamente es más complejo y temporal a menos que se guarden. Generalmente se recomienda usar firewalld o ufw si están disponibles. Para una prueba rápida (no persistente):
      bash sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Necesitarás guardar estas reglas si quieres que persistan después de los reinicios.

    Advertencia: Ten cuidado al modificar las reglas del firewall, especialmente cuando te conectas por SSH a un servidor remoto. Las reglas incorrectas pueden bloquearte permanentemente. Siempre verifica que tus cambios funcionen antes de cerrar tu sesión SSH actual, si tienes una abierta.

Paso 3: Verificar la configuración de SSH (sshd_config)

El archivo de configuración del demonio SSH (/etc/ssh/sshd_config) dicta cómo opera el servicio. Configuraciones erróneas aquí pueden llevar a que las conexiones sean rechazadas.

  1. Localizar sshd_config:
    El archivo de configuración principal se encuentra generalmente en /etc/ssh/sshd_config.

  2. Inspeccionar configuraciones clave:
    Abre el archivo con un editor de texto (por ejemplo, nano, vi):
    bash sudo nano /etc/ssh/sshd_config
    Busca las siguientes directivas:

    • Port: Esto especifica el puerto en el que sshd escucha. Asegúrate de que coincida con el puerto al que intentas conectarte desde tu cliente. Si está comentado (#), el valor predeterminado es el puerto 22.
    • ListenAddress: Si está presente, esto especifica en qué direcciones IP sshd debe escuchar. Si está configurado en una IP interna (por ejemplo, 127.0.0.1) y te estás conectando desde una red externa, rechazará la conexión. Para escuchar en todas las interfaces, a menudo está comentado o configurado como 0.0.0.0 o :: (para IPv6).
    • PermitRootLogin: Si se establece en no, no podrás iniciar sesión como root. Aunque no es una "conexión rechazada" en el sentido más estricto (a menudo es un permiso denegado después de la conexión), puede impedir intentos de inicio de sesión exitosos.
    • PasswordAuthentication: Si se establece en no, la autenticación por contraseña está deshabilitada, requiriendo autenticación basada en claves.

    Consejo: Después de realizar cualquier cambio en sshd_config, debes reiniciar el servicio SSH para que surtan efecto:
    bash sudo systemctl restart sshd

Paso 4: Conectividad de red (Comprobación básica)

Aunque una "conexión rechazada" típicamente significa que se llegó al servidor, siempre es bueno confirmar rápidamente la accesibilidad básica de la red desde tu máquina cliente a la dirección IP del servidor.

  1. Hacer ping al servidor:
    Desde tu máquina cliente, intenta hacer ping a la dirección IP o nombre de host del servidor:
    bash ping <SERVER_IP_ADDRESS_OR_HOSTNAME>
    Si el ping falla (100% de pérdida de paquetes), tienes un problema de red más fundamental (por ejemplo, IP incorrecta, servidor desconectado, problema de enrutamiento de red) que debe abordarse antes de SSH.

  2. Usar nc o telnet (desde el cliente):
    Para probar si el puerto está abierto y escuchando desde la perspectiva del cliente:
    ```bash
    # Usando netcat (nc)
    nc -zv 22

    Usando telnet

    telnet 22
    `` SincmuestraConnection refusedotelnet` se cierra inmediatamente, confirma que el servidor está rechazando activamente en ese puerto, lo que apunta de nuevo al demonio SSH o al firewall.

Paso 5: Verificar SELinux o AppArmor (Avanzado)

En algunos entornos reforzados, o después de configuraciones personalizadas, SELinux (Security-Enhanced Linux) o AppArmor podrían estar impidiendo que sshd funcione correctamente, especialmente si estás utilizando un puerto SSH no estándar.

  1. Verificar el estado de SELinux:
    bash sestatus
    Si SELinux está en modo enforcing (aplicación), es posible que necesites ajustar sus políticas para permitir sshd en un puerto personalizado.
    Por ejemplo, para permitir el puerto 2222 para SSH:
    bash sudo semanage port -a -t ssh_port_t -p tcp 2222 sudo systemctl restart sshd
    (Instala semanage si no está disponible: sudo apt install policycoreutils-python-utils en Debian/Ubuntu, sudo yum install policycoreutils-python en CentOS/RHEL).

  2. Verificar el estado de AppArmor:
    bash sudo aa status
    Si AppArmor está en modo enforcing (aplicación), revisa sus registros (/var/log/syslog o dmesg) en busca de cualquier denegación relacionada con sshd.

Paso 6: Revisar los registros del servidor (De nuevo)

Después de intentar los pasos anteriores, siempre vuelve a verificar los registros del servidor en busca de nuevos mensajes de error relacionados con sshd. Esta es tu fuente definitiva de la verdad sobre lo que el servidor está experimentando.

  • sudo journalctl -u sshd
  • sudo tail -f /var/log/auth.log (o /var/log/secure)

Busca mensajes que indiquen por qué el servicio podría no estar iniciando, por qué se están perdiendo conexiones o cualquier otra información relevante.

Mejores prácticas para prevenir problemas futuros

  • Actualiza regularmente tu sistema operativo: Mantén tu sistema operativo y paquetes del servidor, incluido openssh-server, actualizados.
  • Prueba las reglas del firewall: Después de implementar o modificar las reglas del firewall, pruébalas siempre de inmediato.
  • Haz una copia de seguridad de sshd_config: Antes de realizar cambios en /etc/ssh/sshd_config, haz una copia de seguridad (sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak).
  • Usa una consola de gestión: Para instancias en la nube, aprende a acceder a la consola del servidor (por ejemplo, AWS EC2 Serial Console, Google Cloud Console) para solucionar problemas de red cuando SSH no esté disponible.
  • Monitoriza los registros: Revisa regularmente los registros auth.log o secure en busca de actividad inusual o errores persistentes.

Conclusión

El error 'Connection Refused', aunque frustrante, suele ser sencillo de resolver comprobando sistemáticamente el estado del demonio SSH, las reglas del firewall y el archivo sshd_config. Siguiendo los pasos descritos en esta guía, puedes diagnosticar eficientemente la causa raíz y restaurar tu acceso remoto seguro. Recuerda siempre aplicar los cambios con cautela y verificar la funcionalidad para evitar quedarte fuera de tu servidor.

Con estas técnicas de solución de problemas, estarás bien equipado para abordar los problemas de conexión SSH y mantener un control fluido sobre tus sistemas remotos. ¡Feliz SSHing!