¿Tu SSHD Invalida el Acceso por Claves? Causas Comunes y Cómo Solucionarlo

Imagina esto: intentas acceder a tu servidor remoto, introduces el comando SSH de forma habitual, pero en lugar de la familiar bienvenida de la terminal, te encuentras con un frustrante mensaje de „Permission denied (publickey)”. La sensación es de confusión, ¿verdad? Después de todo, habías configurado tus claves SSH meticulosamente para evitar las tediosas contraseñas y garantizar una seguridad robusta. ¿Qué demonios ha pasado? ¿Por qué tu SSHD parece haber invalidado tu acceso por claves?

No estás solo en esta odisea. Este escenario es sorprendentemente común y, afortunadamente, rara vez se debe a un problema insuperable. En la mayoría de los casos, la raíz del inconveniente reside en pequeños detalles de configuración o permisos que el SSH Daemon (SSHD) interpreta como una señal de alerta de seguridad. Este artículo te guiará a través de las causas más frecuentes de estos fallos y te proporcionará soluciones prácticas y detalladas para restaurar tu acceso por claves.

Comprendiendo el Entramado: Claves SSH y el Rol de SSHD

Antes de sumergirnos en la resolución de problemas, refresquemos la memoria sobre cómo funciona este sistema. Las claves SSH, fundamentales para una autenticación segura y eficiente, operan bajo un esquema de criptografía asimétrica. Posees un par de claves: una clave privada, que guardas celosamente en tu máquina local, y una clave pública, que resides en el servidor remoto al que deseas conectarte.

Cuando inicias una conexión, tu cliente SSH envía una solicitud al servidor. El SSH Daemon (SSHD) del servidor, que es el programa que escucha las conexiones entrantes, busca tu clave pública en un archivo específico (generalmente ~/.ssh/authorized_keys) asociado a tu usuario. Si la encuentra, el SSHD realiza un desafío criptográfico. Si tu cliente puede responder correctamente utilizando tu clave privada, ¡voilà! El acceso es concedido. Es un ballet de seguridad que, cuando se interrumpe, nos deja con un dolor de cabeza.

El meollo de la cuestión es que el SSHD es, por diseño, un guardián extremadamente vigilante. Cualquier desviación de sus estrictos requisitos de seguridad para los archivos de claves y directorios puede llevarlo a rechazar tu autenticación. Y es precisamente en esos „detalles” donde suelen surgir los tropiezos.

Causas Comunes de Fallo en la Autenticación por Claves SSH

Aquí desglosamos las razones más habituales por las que tu SSH Daemon podría estar rechazando tu acceso, incluso con las claves aparentemente correctas:

1. Permisos Incorrectos de Archivos y Directorios ⚠️

Esta es, sin duda, la causa número uno. El SSHD es intransigente con los permisos de los archivos que utiliza para la autenticación. Si el directorio ~/.ssh o el archivo ~/.ssh/authorized_keys tienen permisos demasiado laxos, el daemon asumirá que han sido comprometidos y, por seguridad, denegará el acceso. Incluso el directorio home del usuario (~) puede ser un factor.

• Directorio ~/.ssh: Debe ser accesible solo por el propietario. Permisos recomendados: 700 (rwx------).
• Archivo ~/.ssh/authorized_keys: Debe ser legible solo por el propietario. Permisos recomendados: 600 (rw-------).
• Directorio ~ (home del usuario): Aunque menos común, si tiene permisos de escritura para otros usuarios, puede causar problemas. Lo ideal es 755 o 700.

Solución: Accede al servidor vía contraseña (si aún es posible) o a través de la consola de proveedor y ejecuta los siguientes comandos:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Verifica también los permisos del directorio home del usuario. Si es necesario, ajústalo con chmod 755 ~ o chmod 700 ~.

2. Contenido Erróneo en authorized_keys 📝

Un simple error tipográfico o un formato incorrecto en el archivo authorized_keys puede ser suficiente para que el SSHD no reconozca tu clave.

• Espacios en blanco o saltos de línea: La clave pública debe ser una línea continua, sin saltos de línea, aunque algunas herramientas añaden comentarios al final, lo cual es aceptable.
• Clave incompleta o modificada: Asegúrate de que la clave copiada sea exactamente la que generaste.
• Claves de formatos mixtos: Aunque SSH es flexible, es mejor asegurarse de que la clave sea la adecuada para el formato que el servidor espera (ej. ssh-rsa, ecdsa-sha2-nistp256, ed25519).

Solución: La mejor manera de asegurar que la clave esté bien copiada es usar ssh-copy-id usuario@servidor. Si no es posible, abre el archivo ~/.ssh/authorized_keys en el servidor con un editor de texto (como nano o vi) y compara cuidadosamente su contenido con el de tu clave pública original (generalmente ~/.ssh/id_rsa.pub en tu máquina local). Asegúrate de que no haya caracteres extraños o líneas mal formadas.

3. Configuración del SSHD (sshd_config) ⚙️

El archivo de configuración principal del SSH Daemon, /etc/ssh/sshd_config, contiene directivas cruciales que pueden influir en la autenticación por clave pública.

• PubkeyAuthentication no: Si esta directiva está establecida en no, la autenticación por clave pública estará deshabilitada globalmente. Debe estar en yes.
• AuthorizedKeysFile: Esta directiva especifica la ruta al archivo que contiene las claves públicas. Asegúrate de que apunte al lugar correcto, comúnmente .ssh/authorized_keys (relativo al directorio home del usuario o con una ruta absoluta).
• StrictModes no: Aunque deshabilitar StrictModes podría „resolver” problemas de permisos, no es una práctica recomendada, ya que reduce la seguridad. Lo ideal es mantenerlo en yes y corregir los permisos correctamente.
• AllowUsers, DenyUsers, AllowGroups, DenyGroups: Si tu usuario o grupo está listado en DenyUsers/DenyGroups o no está en AllowUsers/AllowGroups, se te denegará el acceso.
• PermitRootLogin: Si intentas acceder como usuario root, esta directiva debe permitirlo. Los valores comunes son prohibit-password (permite clave, prohíbe contraseña) o yes. Si está en no, no podrás iniciar sesión como root, ni siquiera con claves.

Solución: Edita el archivo /etc/ssh/sshd_config. Una vez realizados los cambios, reinicia el servicio SSHD para que surtan efecto. Los comandos varían según la distribución:

sudo systemctl restart sshd      # Para sistemas basados en systemd (Ubuntu, CentOS 7+, etc.)
sudo service ssh restart         # Para sistemas más antiguos (Ubuntu 14.04, Debian 7)

4. Claves Mal Generadas o Corruptas 🔑

Aunque menos frecuente, es posible que tu par de claves SSH haya sido generado incorrectamente o que la clave privada se haya corrompido. Esto es particularmente relevante si has manipulado el archivo de forma manual.

Solución: Si sospechas que este es el caso, lo más seguro es generar un nuevo par de claves en tu máquina local y luego transferir la nueva clave pública al servidor. Asegúrate de respaldar tus claves existentes si las usas para otros accesos.

5. Problemas de Propietario (Owner Issues) 👤

Al igual que los permisos, el SSHD es muy estricto con la propiedad de los archivos. Si el directorio ~/.ssh o el archivo ~/.ssh/authorized_keys no pertenecen al usuario que intenta iniciar sesión (y a su grupo principal), la autenticación fallará.

Solución: Verifica y corrige el propietario y grupo de los archivos relevantes. Accede al servidor y ejecuta:

sudo chown usuario:grupo_usuario ~/.ssh
sudo chown usuario:grupo_usuario ~/.ssh/authorized_keys

Reemplaza usuario y grupo_usuario con el nombre de usuario y su grupo principal en el servidor.

6. SELinux o AppArmor Bloqueando el Acceso 🛡️

En sistemas con módulos de seguridad como SELinux (CentOS/RHEL) o AppArmor (Ubuntu), las políticas de seguridad pueden anular los permisos de archivos POSIX estándar y bloquear el acceso del SSHD a los archivos de claves, incluso si los permisos parecen correctos. Esto ocurre porque estas herramientas imponen controles de acceso adicionales basados en contextos de seguridad.

Solución: Primero, revisa los logs de auditoría de SELinux (/var/log/audit/audit.log) o los logs del sistema para AppArmor (/var/log/syslog o dmesg) en busca de entradas que denieguen el acceso a SSH o a los archivos de claves. Si encuentras entradas de SELinux, puedes intentar restaurar el contexto de seguridad predeterminado con restorecon -Rv ~/.ssh. Para AppArmor, es posible que necesites ajustar o deshabilitar temporalmente el perfil para /usr/sbin/sshd para diagnosticar.

7. Firewall o Reglas de Seguridad de Red 🔥

Aunque esto impediría la conexión SSH por completo en lugar de „invalidar” la clave, a menudo se percibe como un fallo de autenticación. Si el puerto 22 (o el puerto SSH configurado) está bloqueado por un firewall en el servidor (ufw, firewalld, iptables) o por un firewall de red externo, el cliente no podrá establecer la conexión.

Solución: Verifica la configuración del firewall en tu servidor para asegurarte de que el puerto SSH esté abierto. Por ejemplo, con UFW: sudo ufw status y sudo ufw allow ssh. Si estás detrás de un firewall de red corporativo o de nube, asegúrate de que las reglas de seguridad permitan el tráfico entrante al puerto SSH.

8. Problemas en el Cliente SSH 💻

A veces, la dificultad no reside en el servidor, sino en tu propia máquina cliente.

• Ruta de la clave privada incorrecta: Estás usando un comando SSH que no especifica la clave correcta, o tu ssh-agent no tiene la clave cargada.
• Passphrase incorrecta: Estás introduciendo una contraseña incorrecta para tu clave privada (si tiene una).
• known_hosts obsoleto: Si la huella digital del servidor ha cambiado (quizás por una reinstalación), tu cliente podría negarse a conectar, mostrando una advertencia.

Solución: Asegúrate de especificar la clave correcta con ssh -i /ruta/a/tu/clave_privada usuario@servidor. Carga tu clave en ssh-agent con ssh-add /ruta/a/tu/clave_privada. Si recibes una advertencia sobre known_hosts, puedes eliminar la línea específica del archivo ~/.ssh/known_hosts que contiene la huella digital del servidor (¡con precaución, esto puede ser un ataque man-in-the-middle!).

Diagnóstico: ¿Cómo Saber Dónde Reside el Problema? 🔍

La clave para resolver estos problemas es una buena capacidad de diagnóstico. Aquí te presentamos las herramientas más importantes:

• Cliente SSH Verbosidad (¡Tu mejor amigo!): Utiliza el modo verboso al conectar desde tu cliente.

  ssh -vvv usuario@servidor

  Esto mostrará una gran cantidad de información sobre el proceso de autenticación. Busca líneas como „Authentications that can continue:”, „Offering public key:”, „Server refused our key”, o mensajes relacionados con permisos.

• Logs del Servidor: Los registros del sistema en el servidor son cruciales.
  • En sistemas basados en Debian/Ubuntu: sudo cat /var/log/auth.log | grep sshd
  • En sistemas basados en CentOS/RHEL: sudo cat /var/log/secure | grep sshd

  Busca mensajes que indiquen „authentication failed”, „permission denied”, „bad ownership or modes for directory” o „sshd refused publickey”. Estos mensajes suelen ser muy específicos y te dirán exactamente qué no le gusta al SSHD.

• Verificación de Permisos y Propietarios en el Servidor:

  ls -ld ~/.ssh
  ls -l ~/.ssh/authorized_keys
  ls -ld ~

  Estos comandos te mostrarán los permisos y propietarios de los directorios y archivos clave. Son fundamentales para descartar la causa más común.

Opinión Basada en la Experiencia: ¡La Paciencia es Virtud!

A lo largo de los años trabajando con innumerables servidores y equipos, he llegado a una conclusión ineludible: la inmensa mayoría de los problemas de autenticación por claves SSH, probablemente más del 85%, se reducen a errores humanos básicos. Ya sea un despiste al copiar la clave, unos permisos ligeramente incorrectos o una directiva en sshd_config que pasó desapercibida, la tecnología rara vez falla por sí misma. El SSH Daemon es un programa extremadamente robusto y confiable; su rigor es una característica de seguridad, no un capricho. Por ello, la herramienta más potente en tu arsenal de depuración es la combinación de la verbosidad del cliente (ssh -vvv) y el examen meticuloso de los logs del servidor. Esta dupla te ahorrará horas de frustración, revelando la causa exacta del bloqueo en la mayoría de los casos.

Soluciones Paso a Paso (Recapitulando) ✅

Aquí tienes un resumen de la secuencia de pasos lógicos para abordar este inconveniente:

1. Comienza con Permisos y Propietarios: Siempre es el primer lugar para mirar. Ejecuta chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys y chown usuario:grupo_usuario ~/.ssh ~/.ssh/authorized_keys.
2. Revisa authorized_keys: Asegúrate de que la clave pública esté completa, sin saltos de línea y en el formato correcto.
3. Inspecciona sshd_config: Confirma que PubkeyAuthentication yes esté habilitado y que AuthorizedKeysFile sea correcto. Reinicia SSHD después de cualquier cambio.
4. Utiliza la Verbosidad del Cliente: Ejecuta ssh -vvv usuario@servidor y analiza cuidadosamente la salida. Busca „Authentication failed”, „Server refused our key”, o cualquier indicio de problemas de permisos.
5. Consulta los Logs del Servidor: Revisa /var/log/auth.log o /var/log/secure en el servidor en busca de mensajes de error específicos del SSHD.
6. Considera SELinux/AppArmor: Si los pasos anteriores no revelan nada, verifica los logs de estos módulos de seguridad para descartar bloqueos.
7. Verifica el Cliente: Asegúrate de que estás usando la clave privada correcta y que el ssh-agent la tiene cargada.

Conclusión

El acceso por claves SSH es un pilar de la administración de sistemas modernos, ofreciendo una combinación inigualable de seguridad y conveniencia. Cuando el SSH Daemon decide no cooperar, la frustración puede ser considerable. Sin embargo, al comprender los mecanismos subyacentes y armarse con las herramientas de diagnóstico adecuadas, la mayoría de estos desafíos se pueden superar con un poco de paciencia y un enfoque sistemático.

La próxima vez que tus claves SSH te fallen, respira hondo y sigue estos pasos. Lo más probable es que descubras que la solución es más simple de lo que parecía, y habrás aprendido una lección valiosa sobre la robustez y la exigencia de uno de los protocolos más importantes de Internet.