Diagnóstico y Resolución de Fallos de Autenticación SSH

Secure Shell (SSH) es la base de la administración remota segura, permitiendo el acceso cifrado a servidores y dispositivos de red. Sin embargo, encontrarse con fallos de autenticación es una experiencia común y a menudo frustrante para administradores de sistemas y desarrolladores. Estos problemas pueden deberse a una multitud de causas, que van desde simples errores tipográficos hasta problemas complejos de permisos o configuraciones incorrectas.

Este artículo sirve como una guía completa para diagnosticar y resolver eficazmente los fallos de autenticación SSH. Profundizaremos en métodos sistemáticos de solución de problemas, enfatizando el papel crítico de la salida detallada del lado del cliente y el análisis de registros del lado del servidor. Al comprender cómo interpretar estas pistas de diagnóstico, estarás equipado para identificar la causa raíz de la mayoría de los problemas de autenticación y restaurar tu acceso remoto seguro.

Comprensión de los Métodos de Autenticación SSH

Antes de sumergirnos en la solución de problemas, es esencial comprender los métodos de autenticación principales que emplea SSH:

Autenticación por Contraseña: El usuario proporciona una contraseña, que el servidor verifica contra su base de datos de usuarios o un servicio de autenticación externo (como PAM).
Autenticación por Clave Pública: Este método más seguro utiliza un par de claves criptográficas: una clave privada almacenada en el cliente y una clave pública correspondiente almacenada en el servidor. Al autenticarse, el cliente usa su clave privada para demostrar su identidad sin enviar nunca la clave privada a través de la red.

Los fallos de autenticación pueden ocurrir con cualquiera de los dos métodos, pero los pasos de solución de problemas a menudo difieren.

Verificaciones Iniciales y Errores Comunes

Antes de profundizar en los registros detallados, es prudente realizar algunas verificaciones básicas, ya que muchos problemas suelen ser simples descuidos:

Nombre de Usuario y Hostname Correctos: Vuelve a verificar que estás usando el nombre de usuario correcto y el hostname exacto o la dirección IP del servidor de destino.
Conectividad de Red: ¿Puedes alcanzar el servidor en absoluto? Usa nc -vz host 22 o ssh -vvv para probar la accesibilidad SSH. ping puede ayudar, pero muchos servidores bloquean ICMP incluso cuando SSH está funcionando.
```
ping example.com
```
Estado del Servicio SSH: ¿El servidor SSH (sshd) está realmente ejecutándose en la máquina de destino? Si tienes acceso a la consola, verifica su estado.
```
sudo systemctl status sshd # Para sistemas basados en systemd (la mayoría de Linux moderno)
sudo service sshd status    # Para sistemas init antiguos
```
Puerto SSH: ¿El demonio SSH está escuchando en el puerto predeterminado (22) o en un puerto personalizado? Si es un puerto personalizado, deberás especificarlo con -p.
Reglas de Cortafuegos: ¿Hay algún cortafuegos (del lado del cliente o del servidor) bloqueando el puerto 22 (o tu puerto SSH personalizado)? Verifica cortafuegos del servidor como ufw, firewalld o grupos de seguridad de AWS.
```
sudo ufw status
sudo firewall-cmd --list-all
```

Diagnóstico del Lado del Cliente: Aprovechando el Modo Detallado

El cliente SSH ofrece modos detallados (-v, -vv, -vvv) que proporcionan una salida de depuración detallada sobre el proceso de conexión y los intentos de autenticación. Esta salida es invaluable para entender por qué el cliente cree que la autenticación está fallando.

Uso de Banderas Detalladas

-v: Salida detallada.
-vv: Salida más detallada.
-vvv: Salida aún más detallada (a menudo la más útil para problemas de autenticación).

Comando de Ejemplo:

ssh -vvv usuario@tu_direccion_servidor

Interpretación de la Salida Detallada

Cuando ejecutas ssh en modo detallado, busca líneas clave que indiquen dónde está fallando el proceso de autenticación:

debug1: Authentications that can continue:: Esta línea te dice qué métodos de autenticación está dispuesto a aceptar el servidor. Si tu método deseado (por ejemplo, publickey) no está listado, la configuración del servidor lo está impidiendo.
```
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
```
debug1: Offering public key:: Esto indica que tu cliente está intentando usar una clave pública específica para la autenticación. Si esperas autenticación por clave pública pero no ves esto, tu cliente no está encontrando u ofreciendo la clave.
```
debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
```
debug3: send_pubkey_test: ... trying private key: /home/user/.ssh/id_rsa: Esto confirma que el cliente está intentando usar una clave privada específica.
debug1: Server accepts key: ...: Esto indicaría una autenticación por clave pública exitosa desde la perspectiva del cliente. Si no ves esto, es probable que el servidor haya rechazado la clave.
debug1: No more authentication methods to try.: Esto a menudo aparece justo antes de un error Permission denied y significa que el cliente ha agotado todos los métodos de autenticación disponibles sin éxito.
debug1: Permission denied (publickey,password).: Este es el error final del lado del cliente, que resume el rechazo del servidor a todos los intentos.

Consejo: Presta mucha atención al orden de los métodos de autenticación ofrecidos y aceptados. Si se ofrece publickey pero luego es seguido inmediatamente por un mensaje de contraseña, a menudo significa que el servidor rechazó la clave pública.

Diagnóstico del Lado del Servidor: Examinando los Registros del Servidor SSH

Mientras que la salida detallada del lado del cliente muestra lo que el cliente está intentando hacer, los registros del servidor proporcionan información definitiva sobre por qué el servidor rechazó el intento de autenticación. Este es a menudo el paso más crítico en el análisis de causa raíz.

Localización de los Registros del Servidor SSH

La ubicación de los registros del servidor SSH varía según el sistema operativo:

Debian/Ubuntu y derivados: /var/log/auth.log
RHEL/CentOS/Fedora y derivados: /var/log/secure
Sistemas basados en systemd (la mayoría de Linux moderno): También puedes usar journalctl.

Visualización y Filtrado de Registros del Servidor

Usa herramientas como tail o journalctl para monitorear registros en tiempo real o filtrar entradas específicas de SSH.

Comandos de Ejemplo:

# Para Debian/Ubuntu
sudo tail -f /var/log/auth.log | grep sshd

# Para RHEL/CentOS
sudo tail -f /var/log/secure | grep sshd

# Para sistemas basados en systemd (la forma más robusta de ver registros actuales)
sudo journalctl -u sshd -f

# Para ver todos los registros de sshd desde el principio (útil si el fallo ocurrió antes)
sudo journalctl -u sshd

Entradas Comunes de Registro del Servidor y sus Significados

Busca mensajes relacionados con sshd cuando intentes conectarte. Aquí hay algunas entradas comunes que indican fallos de autenticación:

Failed password for user from IP port ssh2: Indica que falló un intento de autenticación por contraseña. Esto podría deberse a una contraseña incorrecta, o si al usuario no se le permite iniciar sesión mediante contraseña.
Authentication refused: bad ownership or modes for directory /home/user/.ssh: Este es un error muy común de autenticación por clave pública. El directorio .ssh en el servidor tiene permisos incorrectos.
- Solución: chmod 700 /home/user/.ssh
Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys: Otro error común de clave pública, que indica que el archivo authorized_keys tiene permisos incorrectos.
- Solución: chmod 600 /home/user/.ssh/authorized_keys
sshd[PID]: error: Permissions 0777 for '/home/user/.ssh/authorized_keys' are too open.: Indica explícitamente el problema con modos de archivo demasiado permisivos. SSH es muy estricto con los permisos por razones de seguridad.
User username from IP not allowed because not listed in AllowUsers: Al usuario no se le permite iniciar sesión a través de SSH según la directiva AllowUsers en /etc/ssh/sshd_config.
User username from IP not allowed because listed in DenyUsers: Al usuario se le deniega explícitamente el acceso SSH por DenyUsers.
input_userauth_request: invalid user username: El nombre de usuario proporcionado no existe en el servidor.
Failed publickey for user o claves ofrecidas repetidas seguidas de contraseña: la clave pública presentada por el cliente no coincidió con una clave aceptada para ese usuario, o el servidor rechazó la clave debido a permisos o política.
Maximum authentication attempts exceeded for user from IP: El cliente intentó demasiados métodos de autenticación o envió demasiadas credenciales incorrectas. Controlado por MaxAuthTries en sshd_config.
Connection closed by authenticating user IP port 22 [preauth]: Esto puede ocurrir si no se encontró un método de autenticación aceptable, o si el cliente cierra abruptamente la conexión después de un fallo.

Escenarios Comunes de Fallo de Autenticación y Soluciones

Clasifiquemos los fallos comunes y sus remedios específicos.

1. Fallos de Autenticación por Contraseña

Contraseña Incorrecta: El problema más directo. Vuelve a verificar tu contraseña. Ten en cuenta las distribuciones del teclado, Bloq Mayús o Bloq Num.
Usuario No Permitido: El archivo sshd_config (/etc/ssh/sshd_config) podría restringir el inicio de sesión para ciertos usuarios.
- PermitRootLogin no: Impide el inicio de sesión de root (altamente recomendado por seguridad).
- AllowUsers usuario1 usuario2: Solo los usuarios especificados pueden iniciar sesión.
- DenyUsers usuario: Los usuarios especificados no pueden iniciar sesión.
- AllowGroups nombre_grupo: Solo los usuarios en grupos especificados pueden iniciar sesión.
- Solución: Ajusta las directivas de sshd_config y reinicia sshd.
Problemas de PAM: Si el servidor usa Módulos de Autenticación Conectables (PAM), los problemas con la configuración de PAM pueden impedir la autenticación por contraseña. Verifica /var/log/auth.log en busca de errores específicos de PAM. Esto es menos común para configuraciones SSH básicas.

2. Fallos de Autenticación por Clave Pública

La autenticación por clave pública es a menudo más segura pero propensa a más errores relacionados con la configuración.

Permisos Incorrectos de Archivo/Directorio (Lado del Servidor): Esta es, con diferencia, la causa más común. SSH requiere permisos estrictos para ~/.ssh y ~/.ssh/authorized_keys por seguridad.
- ~: El directorio home del usuario no debe ser escribible por el mundo (chmod 755 ~ suele ser seguro).
- ~/.ssh: Debe ser 700 (rwx solo para el propietario).
```
chmod 700 ~/.ssh
```
- ~/.ssh/authorized_keys: Debe ser 600 (rw solo para el propietario).
```
chmod 600 ~/.ssh/authorized_keys
```
- El propietario de estos archivos y directorios debe ser el usuario que intenta iniciar sesión.
```
sudo chown -R usuario:usuario ~/.ssh
```
Contenido Incorrecto de authorized_keys: La clave pública en ~/.ssh/authorized_keys podría estar corrupta, tener caracteres adicionales o estar en un formato incorrecto. Cada clave debe estar en una sola línea. Una forma rápida de asegurar el formato adecuado es usar ssh-copy-id desde el cliente.
```
ssh-copy-id -i ~/.ssh/id_rsa.pub usuario@tu_direccion_servidor
```
Para verificar la huella digital de tu clave pública en el lado del cliente, usa: ssh-keygen -l -f ~/.ssh/id_rsa.pub
Cliente No Ofrece Clave: La clave privada podría no estar en la ubicación predeterminada (~/.ssh/id_rsa), no estar cargada en ssh-agent, o no la has especificado con -i.
- Solución: Asegúrate de que tu clave privada sea id_rsa (o id_ed25519, etc.) en ~/.ssh y tenga permisos 600. Si no, especifícala:
```
ssh -i /ruta/a/tu/clave_privada usuario@tu_direccion_servidor
```
- Si usas ssh-agent, asegúrate de que tu clave esté añadida:
```
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/tu_clave_privada
```
sshd_config Deshabilitando la Autenticación por Clave Pública: El demonio SSH del servidor podría estar configurado para deshabilitar la autenticación por clave pública.
- Verifica PubkeyAuthentication yes en /etc/ssh/sshd_config.
- Verifica AuthorizedKeysFile .ssh/authorized_keys para asegurarte de que apunta al archivo correcto. El valor predeterminado suele ser correcto.
- Solución: Establece PubkeyAuthentication yes y reinicia sshd.
Interferencia de SELinux/AppArmor: En sistemas con SELinux o AppArmor, estos módulos de seguridad a veces pueden bloquear el acceso de SSH a los directorios home de los usuarios o archivos .ssh, incluso si los permisos de archivo son correctos. Verifica los registros de auditoría (/var/log/audit/audit.log o sudo ausearch -m AVC -ts recent) en busca de pistas. Este es un escenario avanzado.

3. Conexión Rechazada o Tiempo de Espera Agotado

Aunque no son estrictamente fallos de "autenticación", a menudo preceden a los intentos de autenticación e impiden que siquiera comiencen.

Cortafuegos Bloqueando: Verifica los cortafuegos tanto en el cliente (por ejemplo, cortafuegos del SO local) como en el servidor (por ejemplo, ufw, firewalld, grupos de seguridad en la nube, ACL de red). Asegúrate de que el puerto 22 (o puerto personalizado) esté abierto.
Servidor SSH No Ejecutándose: El servicio sshd podría no estar activo o haber fallado.
Puerto/IP Incorrecto: Intentar conectarse al puerto o dirección IP incorrectos.

Consejos Generales de Depuración

Verifica sshd_config: Siempre revisa /etc/ssh/sshd_config en el servidor en busca de configuraciones no predeterminadas que puedan estar interfiriendo. Después de hacer cambios, siempre reinicia el demonio SSH: sudo systemctl restart sshd (o sudo service sshd restart).
Prueba con un Nuevo Usuario/Clave: Si es posible, crea un nuevo usuario y un nuevo par de claves pública/privada. Intenta autenticarte con esta configuración nueva. Si funciona, el problema es específico de la configuración del usuario original.
Aísla el Problema: Intenta conectarte desde una máquina cliente diferente. Si funciona, el problema es específico del cliente. Si falla desde múltiples clientes, el problema es específico del servidor.
Aumenta el Nivel de Registro (Lado del Servidor): Para una depuración profunda, puedes establecer temporalmente LogLevel DEBUG en /etc/ssh/sshd_config y reiniciar sshd. Recuerda revertir esta configuración después de solucionar problemas, ya que los registros de depuración pueden ser muy detallados y consumir espacio en disco.

Conclusión

Usa ssh -vvv para ver lo que tu cliente ofrece, luego verifica los registros del servidor para aprender por qué sshd lo rechazó. La mayoría de los fallos de clave pública se reducen a la clave incorrecta, una entrada faltante en authorized_keys, permisos de archivo estrictos o una regla de sshd_config que bloquea al usuario o método.