Solución de Errores Comunes de SSH: Conexión Rechazada y Denegada

Los fallos de SSH son más fáciles de solucionar cuando separas los problemas de transporte de los problemas de autenticación. Conexión rechazada significa que tu cliente SSH llegó a un host, pero nada aceptó la conexión TCP en ese puerto. Permiso denegado significa que el servidor SSH respondió, pero rechazó tu inicio de sesión. Son incidentes diferentes, aunque ambos se sientan como "no puedo entrar".

Mantén una sesión SSH activa abierta mientras cambias la configuración del servidor. La mayoría de las interrupciones dolorosas de SSH ocurren cuando alguien edita /etc/ssh/sshd_config, reinicia el servicio, se desconecta y solo entonces descubre que la nueva configuración bloquea todas las rutas de inicio de sesión.

Entendiendo los Errores: Rechazado vs. Denegado

Lee el mensaje exacto del cliente antes de cambiar cualquier cosa:

Conexión rechazada: el host rechazó activamente la conexión TCP, generalmente porque sshd no está escuchando en ese puerto o un firewall lo está rechazando.
Tiempo de conexión agotado: los paquetes se están descartando o la ruta de red está rota. Esto es más probable que sea un firewall, ruta, VPN, grupo de seguridad o IP incorrecta.
Permiso denegado (publickey): el servidor es accesible, pero no aceptó tu clave.
Permiso denegado (publickey,password): el servidor intentó uno o más métodos de autenticación y los rechazó.
Verificación de clave de host fallida: tu cliente no confía en la identidad del servidor presentada actualmente para ese nombre de host o IP.

Parte 1: Solución de Problemas de Conexión Rechazada

ssh: connect to host example port 22: Connection refused generalmente apunta al host o puerto remoto. La máquina respondió, pero SSH no estaba aceptando conexiones allí.

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 Accionables (en el servidor remoto):

En muchas distribuciones de Linux, el servicio se llama sshd; en Debian y Ubuntu a menudo se llama ssh. Prueba el que use tu sistema:

systemctl status sshd
systemctl status ssh

Si el servicio está inactivo o falló, inícialo:

sudo systemctl start sshd
sudo systemctl enable sshd

Si sshd falla al iniciar después de un cambio de configuración, valida la configuración:

sudo sshd -t

Ese comando es una de las comprobaciones más seguras que puedes ejecutar antes de reiniciar SSH.

2. Verificar el Puerto de Escucha y la Configuración

Por defecto, SSH usa el puerto TCP 22, pero muchos servidores usan un puerto diferente. Si el servidor escucha en 2222, el comando del cliente debe incluirlo:

ssh -p 2222 [email protected]

A. Revisar `sshd_config`

Examina el archivo de configuración de SSH, típicamente ubicado en /etc/ssh/sshd_config. Busca la directiva Port:

# /etc/ssh/sshd_config ejemplo
Port 2222  # Si esto no es 22, debes especificarlo en el lado del cliente

Después de editar el archivo, ejecuta sudo sshd -t antes de recargar. Si la sintaxis es válida, recarga o reinicia el servicio. Recargar suele ser menos disruptivo:

sudo systemctl reload sshd

B. Verificar Sockets de Escucha

Usa ss para confirmar que sshd está escuchando:

sudo ss -tuln | grep 22

# Salida esperada mostrando estado de escucha:
# LISTEN 0      128    0.0.0.0:22               0.0.0.0:*

Si SSH escucha solo en 127.0.0.1:22, los clientes remotos no pueden conectarse. Si escucha en 0.0.0.0:22 o en una interfaz privada específica, el acceso remoto puede ser posible dependiendo de las reglas del firewall.

3. Verificaciones de Firewall y Red

Un firewall que descarta paquetes generalmente causa un tiempo de espera. Un firewall que rechaza paquetes puede causar un rechazo. Verifica tanto el firewall del host como cualquier firewall de red fuera del host.

Comandos Comunes de Firewall (UFW en Ubuntu/Debian):

Asegúrate 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 del firewall
sudo ufw reload

Los grupos de seguridad en la nube, las ACL de red, las rutas VPN y los firewalls de oficina pueden bloquear SSH antes de que el tráfico llegue al servidor. Si sshd está escuchando y el firewall del host está abierto, prueba desde una máquina dentro de la misma red privada. Eso te dice si el problema es local al servidor o en algún lugar a lo largo de la ruta externa.

Parte 2: Solución de Problemas de Permiso Denegado

Si el servidor responde con Permiso denegado, la ruta de red está funcionando. Concéntrate en el nombre de usuario, los métodos de autenticación permitidos, las claves, el estado de la cuenta y los permisos de archivos.

1. Verificar Nombre de Usuario y Contraseña

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

Nombre de usuario: Las imágenes en la nube a menudo usan usuarios específicos como ubuntu, ec2-user, admin, debian o rocky. root puede estar deshabilitado.
Contraseña: Si la autenticación por contraseña está habilitada, verifica errores tipográficos, bloqueo de cuenta, contraseñas caducadas y reglas PAM.
Puerto y host: Una cantidad sorprendente de fallos de autenticación son causados por conectarse al servidor incorrecto que casualmente ejecuta SSH.

Verificación del Lado del Cliente: Para ver la salida de depuración detallada, ejecuta tu cliente con banderas verbosas:

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 por clave falla cuando el cliente ofrece la clave privada incorrecta, el servidor no tiene la clave pública coincidente, los permisos son demasiado abiertos o sshd_config bloquea el inicio de sesión.

A. Permisos Incorrectos en el Directorio `.ssh`

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

En el Servidor Remoto (Corrigiendo Permisos):

# Los permisos del directorio home del usuario suelen estar bien, pero verifica la carpeta .ssh
chmod 700 ~/.ssh

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

También verifica la propiedad:

chown -R "$USER:$USER" ~/.ssh

En el servidor, StrictModes está comúnmente habilitado. Si el directorio home, el directorio .ssh o el archivo authorized_keys es escribible por otros usuarios, sshd puede ignorar la clave.

B. Clave No Presente o Formateada Incorrectamente

Asegúrate de que la clave pública esté en ~/.ssh/authorized_keys del usuario objetivo, una clave por línea. La clave privada permanece en tu cliente. No pegues la clave privada en authorized_keys.

Desde el cliente, fuerza una clave específica mientras depuras:

ssh -i ~/.ssh/id_ed25519 -vvv [email protected]

En la salida verbosa, busca líneas que muestren qué claves se ofrecieron y por qué el servidor las aceptó o rechazó.

C. Configuración del Servidor que Deshabilita Claves

Verifica /etc/ssh/sshd_config en el servidor para asegurarte de que la autenticación por clave esté permitida:

PubkeyAuthentication yes

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

Si están presentes AllowUsers, AllowGroups, DenyUsers o DenyGroups, pueden anular lo que parece una configuración de clave válida. Un usuario con la clave correcta aún puede ser bloqueado por esas directivas.

3. Investigación de Registros del Lado del Servidor

Los registros del servidor generalmente te dicen la razón real de una denegación. Mantén una terminal abierta en el servidor y observa los registros mientras intentas un inicio de sesión desde el cliente.

Ubicaciones Comunes de Registros:

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

Usa grep para filtrar intentos de conexión recientes:

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

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

En sistemas con journaling systemd, esto suele ser más fácil:

sudo journalctl -u sshd -f
sudo journalctl -u ssh -f

Los mensajes de registro pueden mostrar "bad ownership or modes", "user not allowed", "invalid user", "authentication refused" o fallos de cuenta PAM. Esos mensajes son más confiables que adivinar desde el lado del cliente solo.

Fallos de verificación de clave de host

Host key verification failed no es lo mismo que una contraseña o clave incorrecta. Significa que tu cliente tiene una identidad de servidor guardada para ese nombre de host o IP, y el servidor ahora presenta una identidad diferente. Eso puede ocurrir después de una reconstrucción, reutilización de IP, cambio de balanceador de carga o un riesgo real de intermediario.

No elimines ciegamente la advertencia en un entorno de producción. Verifica la huella digital del servidor a través de tu consola en la nube, gestión de configuración o un canal de confianza existente. Una vez que sepas que el cambio es esperado, elimina la entrada antigua:

ssh-keygen -R example.com
ssh-keygen -R 192.0.2.10

Luego conéctate de nuevo y acepta la nueva clave de host solo si la huella digital coincide con lo que esperas.

Resumen de Mejores Prácticas para un Acceso SSH Confiable

Usa pares de claves: Deshabilita la autenticación por contraseña solo después de haber probado el acceso por clave en una segunda sesión.
Limita quién puede iniciar sesión: Usa AllowUsers o AllowGroups cuando sea apropiado, pero documéntalo para que futuros operadores no persigan problemas de permisos falsos.
Usa PermitRootLogin no: Prefiere usuarios normales con sudo.
Respaldar la configuración: Antes de cambiar /etc/ssh/sshd_config, cópialo:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F) ``` 5. Validar antes de recargar: Ejecuta sudo sshd -t. 6. Mantén una ruta de emergencia: Para servidores en la nube, sabe cómo usar la consola serie, el modo de rescate, la función de conexión de instancia o la gestión de configuración si SSH se rompe.

El camino más corto a través de la solución de problemas de SSH es: identificar el error exacto, probar si el servidor está escuchando, probar si la ruta de red llega a ese puerto, luego leer los registros del servidor para fallos de autenticación. Adivinar generalmente lleva más tiempo que ejecutar esas comprobaciones en orden.