Domina herramientas y mejores prácticas de DevOps - DevOps Knowledge Hub Domina herramientas y mejores prácticas de DevOps - DevOps Knowledge Hub

Cómo solucionar rápidamente errores de conexión SSH rechazada

Soluciona errores de conexión SSH rechazada verificando el estado de sshd, puertos, reglas de firewall, sshd_config, SELinux y registros del servidor.

Cómo solucionar rápidamente errores de conexión SSH rechazada

SSH (Secure Shell) es la columna vertebral de la administración remota de servidores, 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 que te impide acceder a tus sistemas críticos.

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

Entendiendo el error 'Conexión rechazada'

Cuando recibes un error Connection refused, significa que tu cliente SSH llegó exitosamente al servidor remoto, pero el servidor denegó explícitamente la conexión en el puerto especificado. Esto es diferente de un error Connection timed out (donde el cliente no pudo alcanzar el servidor en absoluto) o un error No route to 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á funcionando, un firewall bloquea la conexión o una mala configuración dentro del propio servicio SSH.

Causas comunes de 'Conexión rechazada'

Varios factores pueden llevar a que una conexión SSH sea rechazada. Entenderlos 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 bloqueado, detenido o no haber iniciado al arrancar.
  • Firewall bloqueando el puerto 22 (o puerto personalizado): El firewall del servidor (ej., UFW, firewalld, iptables) está impidiendo conexiones entrantes en el puerto SSH.
  • Configuración incorrecta del demonio SSH: El archivo sshd_config podría estar mal configurado, haciendo que el demonio SSH escuche en un puerto diferente, en una interfaz de red incorrecta, o rechace 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 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

Vamos a sumergirnos en los pasos prácticos para diagnosticar y solucionar el error 'Conexión rechazada'.

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 funcionando en tu máquina remota. Normalmente necesitarás acceso a la consola (ej., 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 (aquellas que usan systemd como Ubuntu, CentOS 7+, Debian 8+):
    sudo systemctl status sshd

En Debian/Ubuntu, el servicio puede llamarse ssh:

sudo systemctl status ssh ``` Si sshd no está funcionando, la salida indicará inactive (dead) o un estado similar.

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

O en Debian/Ubuntu:

sudo systemctl start ssh ```

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

O en Debian/Ubuntu:

sudo systemctl enable ssh ```

  1. Verificar los registros del demonio SSH: Si sshd falla al iniciar, sus registros pueden proporcionar pistas cruciales. Para sistemas systemd:
    sudo journalctl -u sshd --since "10 minutes ago"

O, si tu distro usa la unidad ssh:

sudo journalctl -u ssh --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 del lado del servidor es a menudo 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 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:
      sudo ufw status verbose
      Busca reglas que permitan tráfico en port 22 (o tu puerto SSH personalizado). Si SSH está listado, asegúrate de que esté ALLOWed.
    • firewalld:
      sudo firewall-cmd --list-all
      Verifica las secciones services y ports para ssh o port 22/tcp.
    • iptables:
      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:
      sudo ufw allow ssh        # Permite el puerto 22
# O, para un puerto personalizado (ej., 2222):
sudo ufw allow 2222/tcp
sudo ufw enable           # Si UFW está inactivo
    • firewalld:
      sudo firewall-cmd --permanent --add-service=ssh
# O, para un puerto personalizado (ej., 2222):
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
    • iptables: Agregar reglas 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):
      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 reinicios.

    Advertencia: Ten cuidado al modificar las reglas del firewall, especialmente cuando te conectas por SSH a un servidor remoto. 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 SSH (sshd_config)

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

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

  2. Inspeccionar configuraciones clave: Abre el archivo con un editor de texto (ej., nano, vi):

    sudo nano /etc/ssh/sshd_config

    Busca las siguientes directivas:

    • Port: 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 (#), por defecto es el puerto 22.
    • ListenAddress: Si está presente, especifica en qué direcciones IP debe escuchar sshd. Si está configurado en una IP interna (ej., 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 está configurado como no, no podrás iniciar sesión como root. Aunque no es un "rechazo de conexión" en sentido estricto (a menudo es un permiso denegado después de la conexión), puede evitar intentos de inicio de sesión exitosos.
    • PasswordAuthentication: Si está configurado como no, la autenticación por contraseña está deshabilitada, requiriendo autenticación basada en clave.

    Consejo: Después de hacer cualquier cambio en sshd_config, debes reiniciar el servicio SSH para que surtan efecto:

    sudo systemctl restart sshd

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

Aunque un "rechazo de conexión" típicamente significa que se alcanzó el 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:

    ping <SERVER_IP_ADDRESS_OR_HOSTNAME>

    Si el ping falla (100% de pérdida de paquetes), tienes un problema de red más fundamental (ej., IP incorrecta, servidor fuera de línea, problema de enrutamiento de red) que debe resolverse 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:

    # Usando netcat (nc)
nc -zv <SERVER_IP_ADDRESS> 22

# Usando telnet
telnet <SERVER_IP_ADDRESS> 22

    Si nc muestra Connection refused o telnet sale inmediatamente, confirma que el servidor está rechazando activamente en ese puerto, apuntando de nuevo al demonio SSH o al firewall.

Paso 5: Verificar SELinux o AppArmor (Avanzado)

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

  1. Verificar el estado de SELinux:

    sestatus

    Si SELinux está enforcing, es posible que necesites ajustar sus políticas para permitir sshd en un puerto personalizado. Por ejemplo, para permitir el puerto 2222 para SSH:

    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-utils o el paquete correspondiente para tu versión de la familia RHEL).

  2. Verificar el estado de AppArmor:

    sudo aa status

    Si AppArmor está enforcing, revisa sus registros (/var/log/syslog o dmesg) en busca de denegaciones relacionadas 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 verdad sobre lo que está experimentando el servidor.

  • 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 rechazando conexiones, o cualquier otra información relevante.

Mejores prácticas para prevenir problemas futuros

  • Actualiza tu sistema operativo regularmente: Mantén actualizados el sistema operativo de tu servidor y los paquetes, incluyendo openssh-server.
  • Prueba las reglas del firewall: Después de implementar o modificar reglas del firewall, pruébalas inmediatamente.
  • Respaldar sshd_config: Antes de hacer cambios en /etc/ssh/sshd_config, haz una copia de seguridad (sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak).
  • Usar una consola de administración: Para instancias en la nube, sabe cómo acceder a la consola del servidor (ej., Consola Serie EC2 de AWS, Consola de Google Cloud) para solucionar problemas de red cuando SSH no está disponible.
  • Monitorear registros: Revisa regularmente los registros auth.log o secure en busca de actividad inusual o errores persistentes.

Conclusión final

Un error de conexión SSH rechazada generalmente significa que el servidor es accesible pero nada está aceptando tu conexión en ese puerto. Verifica el nombre del servicio SSH para tu distribución, confirma que el puerto está escuchando, abre el firewall, valida sshd_config y lee los registros antes de hacer cambios más grandes. Si todavía tienes una sesión de trabajo abierta, mantenla abierta hasta que un nuevo inicio de sesión tenga éxito.