Solución de problemas de errores comunes de SSH: Conexión rechazada y permiso denegado

Secure Shell (SSH) es la base de la administración remota de sistemas, proporcionando comunicación cifrada para acceder a servidores. Sin embargo, encontrar errores de conexión puede detener la productividad de inmediato. Los dos errores más comunes y frustrantes que enfrentan los usuarios son "Conexión rechazada" y "Permiso denegado".

Esta guía lo guiará a través de un enfoque sistemático para diagnosticar y resolver estos problemas. Al comprender las causas típicas, que van desde obstrucciones de red hasta configuraciones de autenticación incorrectas, puede restaurar rápidamente el acceso seguro a sus máquinas remotas. Cubriremos verificaciones esenciales, desde verificar el estado del servidor hasta depurar mecanismos de autenticación.

Comprensión de los errores: Rechazado vs. Denegado

Es crucial diferenciar entre los dos mensajes de error principales, ya que apuntan a causas fundamentales muy diferentes:

Conexión rechazada: Esto generalmente significa que la conexión de red llegó al servidor, pero nada estaba escuchando en el puerto especificado, o el sistema operativo rechazó activamente el intento de conexión.
Permiso denegado: Esto implica que el servicio SSH (sshd) recibió con éxito la solicitud de conexión, pero el intento de autenticación (contraseña o clave) falló según la configuración del servidor.

Parte 1: Solución de problemas de conexión rechazada

"Conexión rechazada" (a menudo visto como ssh: connect to host <hostname> port 22: Connection refused) normalmente apunta a un problema del lado del servidor que impide que el demonio acepte conexiones entrantes.

1. Verificar el estado del demonio SSH (sshd)

La causa más común de rechazo es que el proceso del servidor SSH no se está ejecutando o se ha bloqueado.

Pasos prácticos (en el servidor remoto):

Verifique el estado del servicio usando systemctl (común en distribuciones Linux modernas):

systemctl status sshd

Si el estado muestra inactive o failed, inicie el servicio:

sudo systemctl start sshd
# Habilítelo para que se inicie automáticamente al arrancar
sudo systemctl enable sshd

2. Verificar el puerto de escucha y la configuración

Por defecto, SSH se ejecuta en el puerto TCP 22. Si el puerto se ha cambiado por motivos de seguridad, debe especificar el puerto correcto al conectarse o asegurarse de que el servidor esté escuchando en el puerto esperado.

A. Revisar `sshd_config`

Examine el archivo de configuración de SSH, que generalmente se encuentra en /etc/ssh/sshd_config. Busque la directiva Port:

# Ejemplo de /etc/ssh/sshd_config
Port 2222  # Si esto no es 22, debe especificarlo en el lado del cliente

Si cambia este archivo, debe reiniciar el servicio sshd para que los cambios surtan efecto.

B. Verificar sockets de escucha

Use ss o netstat para confirmar que sshd está escuchando activamente en la interfaz y el puerto esperados. Aquí verificamos el puerto 22:

# Usando ss (preferido en sistemas modernos)
sudo ss -tuln | grep 22

# Salida esperada que muestra el estado de escucha:
# LISTEN 0      128    0.0.0.0:22               0.0.0.0:*

Si no aparece nada para el puerto 22, el demonio no se está ejecutando o está configurado para escuchar en una dirección/puerto diferente.

3. Verificaciones de firewall y red

Un firewall que bloquea el tráfico antes de que llegue al proceso sshd a menudo resultará en un tiempo de espera agotado, pero a veces puede presentarse como un rechazo. Es esencial confirmar las reglas del firewall del lado del servidor.

Comandos comunes de firewall (UFW en Ubuntu/Debian):

Asegúrese de que el tráfico SSH esté permitido:

# Verificar estado actual
sudo ufw status

# Permitir tráfico en el puerto predeterminado 22
sudo ufw allow ssh
# O por número de puerto
sudo ufw allow 22/tcp

# Recargar reglas de firewall
sudo ufw reload

⚠️ Advertencia sobre firewalls externos: Si se está conectando desde una red remota, asegúrese de que cualquier dispositivo de red intermedio, grupos de seguridad en la nube (como Grupos de Seguridad de AWS o NSG de Azure) o firewalls de hardware estén permitiendo explícitamente el tráfico en el puerto SSH.

Parte 2: Solución de problemas de permiso denegado

Si se conecta exitosamente al servidor pero recibe inmediatamente "Permiso denegado (publickey,password)", el problema se limita estrictamente a la autenticación.

1. Verificar nombre de usuario y contraseña

Esta es la verificación más simple, pero a menudo se pasa por alto:

Nombre de usuario: ¿Está utilizando el nombre de usuario correcto para el sistema de destino? Es posible que el inicio de sesión root esté deshabilitado.
Contraseña: Si utiliza la autenticación por contraseña, verifique las mayúsculas, los errores tipográficos y asegúrese de que la cuenta no esté bloqueada.

Verificación del lado del cliente: Para ver una salida de depuración detallada, ejecute su cliente con indicadores de verbosidad:

ssh -vvv user@hostname

Esta salida mostrará claramente qué métodos de autenticación intentó el cliente y cuáles rechazó el servidor.

2. Fallos de autenticación basada en claves

La autenticación basada en claves es superior, pero los errores de configuración son causas frecuentes de denegación.

A. Permisos incorrectos en el directorio `.ssh`

SSH es extremadamente estricto con los permisos de archivos por motivos de seguridad. Si los permisos son demasiado abiertos, el servidor ignorará el archivo de clave por completo.

En el servidor remoto (corrección de permisos):

# Los permisos del directorio de inicio del usuario suelen estar bien, pero verifique la carpeta .ssh
chmod 700 ~/.ssh

# El archivo authorized_keys solo debe ser escribible por el propietario
chmod 600 ~/.ssh/authorized_keys

B. Clave no presente o formateada incorrectamente

Asegúrese de que su clave pública (id_rsa.pub o similar) esté correctamente agregada al archivo ~/.ssh/authorized_keys del servidor para el usuario de destino. Cada clave debe estar en su propia línea, sin saltos de línea insertados en medio de la cadena de la clave.

C. Configuración del servidor que deshabilita las claves

Verifique /etc/ssh/sshd_config en el servidor para asegurarse de que se permite la autenticación por clave:

PubkeyAuthentication yes

# Asegúrese de que la autenticación por contraseña no esté deshabilitada si depende de contraseñas
PasswordAuthentication yes

3. Investigación de registros del lado del servidor

Cuando falla la autenticación, los registros del servidor son la fuente de verdad definitiva. Busque mensajes relacionados con el intento de inicio de sesión fallido.

Ubicaciones comunes de registros:

Debian/Ubuntu: /var/log/auth.log
RHEL/CentOS/Fedora: /var/log/secure

Use grep para filtrar intentos de conexión recientes:

# En sistemas RHEL/CentOS
sudo grep 'Failed password' /var/log/secure

# O busque actividad general de SSH
sudo tail -f /var/log/secure

Los mensajes de registro a menudo indican explícitamente por qué se rechazó la clave (por ejemplo, opciones incorrectas, no se encontró una clave coincidente o contexto de usuario incorrecto).

Resumen de mejores prácticas para un acceso SSH confiable

Use pares de claves: Deshabilite la autenticación por contraseña (PasswordAuthentication no) en sshd_config una vez que se haya verificado el acceso por clave.
Cambie el puerto predeterminado: Mover SSH del puerto 22 reduce el ruido de los escaneos automatizados.
Use PermitRootLogin no: Fuerce el acceso administrativo a través de usuarios estándar, forzando el uso de sudo.
Respalde la configuración: Antes de realizar cambios significativos en /etc/ssh/sshd_config, siempre respalde el archivo original:
bash sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
Pruebe localmente: Después de los cambios de configuración, pruebe la conectividad localmente en el servidor (si es posible) antes de desconectar su sesión activa para evitar quedarse fuera.

Al verificar sistemáticamente el estado del servicio, la ruta de red y las capas de configuración de autenticación, puede resolver rápidamente los frustrantes errores Connection Refused y Permission Denied inherentes a la gestión de acceso remoto.