Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Diagnóstico y resolución de fallos de autenticación SSH

¿Tienes problemas con los fallos de autenticación SSH? Esta guía completa proporciona instrucciones paso a paso para diagnosticar y resolver problemas comunes. Aprende a usar eficazmente el modo detallado del cliente (`ssh -vvv`) para entender los intentos de conexión e interpretar los registros del lado del servidor (`/var/log/auth.log` o `/var/log/secure`) para una identificación definitiva de errores. Cubrimos escollos comunes como permisos incorrectos, claves públicas mal configuradas y ajustes del servidor, ofreciendo soluciones prácticas para restaurar tu acceso remoto seguro de forma rápida y eficiente.

43 vistas

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

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

Este artículo sirve como una guía completa para diagnosticar y resolver eficazmente los fallos de autenticación SSH. Profundizaremos en métodos de solución de problemas sistemáticos, enfatizando el papel crítico de la salida detallada (verbose) 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á equipado para identificar la causa raíz de la mayoría de los problemas de autenticación y restaurar su 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 utiliza SSH:

  • Autenticación por Contraseña: El usuario proporciona una contraseña que el servidor verifica con 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 utiliza 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 para solucionarlos a menudo difieren.

Comprobaciones Iniciales y Errores Comunes

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

  • Nombre de Usuario y Nombre de Host Correctos: Verifique dos veces que está utilizando el nombre de usuario correcto y el nombre de host o la dirección IP exactos del servidor de destino.
  • Conectividad de Red: ¿Puede alcanzar el servidor en absoluto? Utilice ping para verificar la accesibilidad básica de la red.
    bash ping example.com
  • Estado del Servicio SSH: ¿Está realmente en ejecución el servidor SSH (sshd) en la máquina de destino? Si tiene acceso a la consola, compruebe su estado.
    bash sudo systemctl status sshd # Para sistemas basados en systemd (la mayoría de los Linux modernos) sudo service sshd status # Para sistemas init más antiguos
  • Puerto SSH: ¿Está el demonio SSH escuchando en el puerto predeterminado (22) o en un puerto personalizado? Si es un puerto personalizado, deberá especificarlo con -p.
  • Reglas de Firewall: ¿Hay algún cortafuegos (del lado del cliente o del servidor) que bloquee el puerto 22 (o su puerto SSH personalizado)? Compruebe los cortafuegos del servidor como ufw, firewalld o los grupos de seguridad de AWS.
    bash 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 e intentos de autenticación. Esta salida es invaluable para comprender por qué el cliente cree que la autenticación está fallando.

Uso de Indicadores Detallados (Verbose Flags)

  • -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 username@your_server_ip

Interpretación de la Salida Detallada

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

  • debug1: Authentications that can continue:: Esta línea le indica qué métodos de autenticación está dispuesto a aceptar el servidor. Si el método deseado (ej. publickey) no aparece en la lista, 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 su cliente está intentando utilizar una clave pública específica para la autenticación. Si espera la autenticación por clave pública pero no ve esto, es posible que su 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 utilizar 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 ve esto, es probable que el servidor haya rechazado la clave.
  • debug1: No more authentication methods to try.: Esto suele aparecer justo antes de un error de Permission denied (Permiso denegado) 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: Preste mucha atención al orden de los métodos de autenticación ofrecidos y aceptados. Si se ofrece publickey pero inmediatamente le sigue un aviso para introducir contraseña, a menudo significa que el servidor rechazó la clave pública.

Diagnóstico del Lado del Servidor: Examen de los Registros del Servidor SSH

Mientras que la salida detallada 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 suele ser el paso más crítico en el análisis de la 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 los Linux modernos): También puede usar journalctl.

Visualización y Filtrado de Registros del Servidor

Utilice herramientas como tail o journalctl para monitorear los 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 los 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 Registros del Servidor y su Significado

Busque mensajes relacionados con sshd cuando intente conectarse. Aquí hay algunas entradas comunes que indican fallos de autenticación:

  • Failed password for user from IP port ssh2: Indica que un intento de autenticación por contraseña falló. Esto podría deberse a una contraseña incorrecta, o si no se permite al usuario iniciar sesión mediante contraseña.
  • Authentication refused: bad ownership or modes for directory /home/user/.ssh: Este es un error de autenticación por clave pública muy común. 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: El usuario no tiene permitido iniciar sesión a través de SSH de acuerdo con la directiva AllowUsers en /etc/ssh/sshd_config.
  • User username from IP not allowed because listed in DenyUsers: El usuario tiene denegado explícitamente el acceso SSH por DenyUsers.
  • input_userauth_request: invalid user username: El nombre de usuario proporcionado no existe en el servidor.
  • Publickey authentication refused: authenticate using identity file.: Esto generalmente significa que la clave pública presentada por el cliente no coincide con ninguna clave en el archivo authorized_keys del servidor para ese usuario, o que el formato de la clave es incorrecto.
  • Maximum authentication attempts exceeded for user from IP: El cliente intentó demasiados métodos de autenticación o envió credenciales incorrectas demasiadas veces. Controlado por MaxAuthTries en sshd_config.
  • Connection closed by authenticating user IP port 22 [preauth]: Esto puede ocurrir si no se encontró ningún 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

Vamos a categorizar los fallos comunes y sus remedios específicos.

1. Fallos de Autenticación por Contraseña

  • Contraseña Incorrecta: El problema más sencillo. Verifique su contraseña. Tenga en cuenta las distribuciones de 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 de ciertos usuarios.
    • PermitRootLogin no: Evita el inicio de sesión de root (muy recomendado por seguridad).
    • AllowUsers username1 username2: Solo los usuarios especificados pueden iniciar sesión.
    • DenyUsers username: Los usuarios especificados no pueden iniciar sesión.
    • AllowGroups groupname: Solo los usuarios de los grupos especificados pueden iniciar sesión.
    • Solución: Ajustar las directivas de sshd_config y reiniciar sshd.
  • Problemas de PAM: Si el servidor utiliza Módulos de Autenticación Enlazables (PAM), los problemas con la configuración de PAM pueden impedir la autenticación por contraseña. Revise /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 suele ser 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 principal del usuario no debe tener permisos de escritura para otros (chmod 755 ~ suele ser seguro).
    • ~/.ssh: Debe ser 700 (rwx solo para el propietario).
      bash chmod 700 ~/.ssh
    • ~/.ssh/authorized_keys: Debe ser 600 (rw solo para el propietario).
      bash chmod 600 ~/.ssh/authorized_keys
    • El propietario de estos archivos y directorios debe ser el usuario que intenta iniciar sesión.
      bash sudo chown -R username:username ~/.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 correcto es usar ssh-copy-id desde el cliente.
    bash ssh-copy-id -i ~/.ssh/id_rsa.pub username@your_server_ip
    Para verificar la huella digital de su clave pública en el lado del cliente, utilice: ssh-keygen -l -f ~/.ssh/id_rsa.pub
  • El Cliente No Ofrece la Clave: La clave privada podría no estar en la ubicación predeterminada (~/.ssh/id_rsa), no estar cargada en ssh-agent, o usted no la especificó con -i.
    • Solución: Asegúrese de que su clave privada sea id_rsa (o id_ed25519, etc.) en ~/.ssh y tenga permisos 600. Si no es así, especifíquela:
      bash ssh -i /path/to/your/private_key username@your_server_ip
    • Si utiliza ssh-agent, asegúrese de que su clave esté añadida:
      bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/your_private_key
  • sshd_config Desactiva la Autenticación por Clave Pública: El demonio SSH del servidor podría estar configurado para no permitir la autenticación por clave pública.
    • Compruebe PubkeyAuthentication yes en /etc/ssh/sshd_config.
    • Compruebe AuthorizedKeysFile .ssh/authorized_keys para asegurarse de que apunta al archivo correcto. El valor predeterminado suele ser correcto.
    • Solución: Establezca PubkeyAuthentication yes y reinicie sshd.
  • Interferencia de SELinux/AppArmor: En sistemas con SELinux o AppArmor, estos módulos de seguridad a veces pueden impedir que SSH acceda a los directorios principales de los usuarios o a los archivos .ssh, incluso si los permisos de archivo son correctos. Busque pistas en los registros de auditoría (/var/log/audit/audit.log o sudo ausearch -m AVC -ts recent). Este es un escenario avanzado.

3. Rechazo de Conexión o Tiempo de Espera Agotado (Timeout)

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

  • Bloqueo por Firewall: Compruebe los cortafuegos tanto en el cliente (ej. cortafuegos local del SO) como en el servidor (ej. ufw, firewalld, grupos de seguridad en la nube, ACL de red). Asegúrese de que el puerto 22 (o el puerto personalizado) esté abierto.
  • Servidor SSH No en Ejecución: El servicio sshd podría no estar activo o se ha bloqueado.
  • Puerto/IP Incorrectos: Intento de conexión a un puerto o dirección IP equivocados.

Consejos Generales de Depuración

  • Revise sshd_config: Siempre revise /etc/ssh/sshd_config en el servidor en busca de cualquier configuración no predeterminada que pueda estar interfiriendo. Después de realizar cambios, reinicie siempre el demonio SSH: sudo systemctl restart sshd (o sudo service sshd restart).
  • Pruebe con un Nuevo Usuario/Clave: Si es posible, cree un nuevo usuario y un nuevo par de claves pública/privada. Intente autenticarse con esta configuración nueva. Si funciona, el problema es específico de la configuración del usuario original.
  • Aísle el Problema: Intente conectarse desde una máquina cliente diferente. Si funciona, el problema es específico del cliente. Si falla desde varios clientes, el problema es específico del servidor.
  • Aumente LogLevel (Lado del Servidor): Para una depuración profunda, puede establecer temporalmente LogLevel DEBUG en /etc/ssh/sshd_config y reiniciar sshd. Recuerde revertir esta configuración después de la solución de problemas, ya que los registros de depuración pueden ser muy detallados y consumir espacio en disco.

Conclusión

Diagnosticar los fallos de autenticación SSH requiere un enfoque sistemático, que combine la salida detallada del lado del cliente con el análisis de registros del lado del servidor. Al examinar meticulosamente las pistas proporcionadas por ssh -vvv y los registros del demonio SSH (auth.log o secure), puede identificar eficazmente el punto exacto del fallo, ya sea una contraseña incorrecta, una clave pública mal configurada, permisos de archivo estrictos o una configuración del lado del servidor.

Recuerde comenzar con las comprobaciones sencillas, luego pasar a la salida detallada del lado del cliente y, finalmente, aprovechar las ideas definitivas de los registros del servidor. Con estas técnicas, estará bien equipado para resolver incluso los problemas de autenticación SSH más complejos y mantener un acceso seguro a sus sistemas remotos.