Linux

Guía Definitiva para Diagnosticar y Solucionar el Error Permission Denied (publickey) en Linux

Por Equipo de SolucionaPC · · 5 min de lectura

Introducción al Error Permission Denied (publickey) en Entornos Linux

Uno de los problemas más frustrantes a los que se enfrentan los administradores de sistemas y desarrolladores al gestionar servidores remotos basados en Linux es el fallo de autenticación Permission denied (publickey). Este mensaje aparece típicamente al intentar establecer una conexión remota mediante Secure Shell (SSH), impidiendo por completo el acceso a la máquina. Aunque a primera vista parece un inconveniente simple de credenciales, sus raíces técnicas suelen ser complejas y estar profundamente imbricadas en la configuración de permisos de archivos críticos, inadaptación de claves criptográficas, o directivas restrictivas dentro del demonio SSH.

A lo largo de esta guía técnica exhaustiva, analizaremos de manera minuciosa los factores desencadenantes de este comportamiento en distribuciones Linux modernas (como Ubuntu, Debian, CentOS y RHEL). Además, implementaremos una metodología de diagnóstico forense basada en verbosidad avanzada y desplegaremos cuatro métodos de solución rigurosamente probados para restaurar el acceso seguro a tu infraestructura.

Análisis Profundo de las Causas Raíz

Para resolver eficazmente este fallo, es imperativo comprender qué sucede a nivel de protocolo cuando el cliente SSH intenta autenticarse ante el servidor. El proceso de autenticación de llave pública requiere una sincronización perfecta entre el componente local que posee la llave privada y el componente remoto que almacena la llave pública correspondiente en el archivo authorized_keys.

Las causas más comunes que rompen este ecosistema de seguridad incluyen:

  • Permisos incorrectos en el sistema de archivos: Linux es extremadamente estricto con los permisos de la carpeta ~/.ssh y sus archivos internos. Si el directorio personal, la carpeta oculta o el archivo authorized_keys tienen permisos de escritura para el grupo o otros usuarios (por ejemplo, permisos 777 o 775), el servidor SSH rechazará la clave por motivos de seguridad preventiva.
  • Incompatibilidad o falta de carga del agente SSH: El cliente local puede tener múltiples claves, pero si el agente SSH (ssh-agent) no tiene cargada la identidad correcta, intentará autenticarse con claves obsoletas o vacías, agotando los intentos permitidos.
  • Desconfiguración en el archivo sshd_config: Directivas restrictivas en el lado del servidor, como la desactivación explícita de PubkeyAuthentication o la prohibición de logins para usuarios específicos, bloquearán el acceso incluso si las llaves son matemáticamente correctas.
  • Problemas de propiedad de usuario (UID/GID): Si la propiedad del directorio .ssh no pertenece al usuario con el que se intenta iniciar sesión (sino por ejemplo a root debido a una mala ejecución de sudo), el sistema denegará la lectura.

Método 1: Diagnóstico Forense Avanzado con Verbosity Extrema

Antes de aplicar cualquier modificación a ciegas, debemos extraer los registros de depuración detallados tanto del lado del cliente como del servidor. Esto nos permitirá identificar el momento exacto en el que falla el intercambio criptográfico.

  1. Ejecuta el cliente SSH incrementando el nivel de depuración al máximo (-vvv) para observar la traza completa de negociación:
ssh -vvv usuario@tu-servidor-ip

Analiza la salida en busca de líneas como "Permission denied (publickey)" y verifica qué llaves está ofreciendo el cliente. Si no aparece la llave esperada, el cliente no la tiene en su memoria activa.

  1. En el servidor remoto (al cual quizás debas acceder mediante consola de rescate o VNC), examina los registros en tiempo real del demonio SSH ejecutando:
sudo journalctl -u ssh -f

O en sistemas basados en RedHat:

sudo tail -f /var/log/secure

Busca errores específicos como "Authentication refused: bad ownership or modes for directory", lo cual te dará la pista inequívoca para proceder al siguiente método.

Método 2: Corrección Estricta de Permisos y Propietarios

Dado que los permisos incorrectos son la causa número uno de este error, debemos restablecer la jerarquía de seguridad estándar exigida por OpenSSH en el directorio home del usuario remoto.

  1. Conéctate a la consola física o de emergencia de tu servidor Linux y asegúrate de que el propietario del directorio personal y todo su contenido sea estrictamente el usuario afectado:
sudo chown -R $USER:$USER /home/$USER
  1. Aplica los permisos restrictivos recomendados por los estándares de seguridad POSIX. El directorio .ssh jamás debe tener permisos de escritura para grupos u otros:
chmod 700 /home/$USER/.ssh
  1. Ajusta los permisos del archivo que almacena las llaves públicas autorizadas:
chmod 600 /home/$USER/.ssh/authorized_keys
  1. Si existen archivos de llave privada en el directorio .ssh del servidor (lo cual no es habitual pero puede ocurrir), asegúrate de que sus permisos sean estrictamente privados:
chmod 600 /home/$USER/.ssh/id_rsa

Método 3: Verificación, Carga Manual y Depuración del Agente SSH

A menudo, el error persiste porque el cliente local no está transmitiendo la clave privada adecuada al servidor. Vamos a gestionar esto de forma limpia.

  1. Inicia el agente SSH en tu máquina local en segundo plano:
eval "$(ssh-agent -s)"
  1. Añade explícitamente tu clave privada al agente, reemplazando la ruta por la ubicación de tu archivo de identidad:
ssh-add ~/.ssh/id_ed25519

Nota: Si utilizas una clave RSA tradicional, asegúrate de apuntar a ~/.ssh/id_rsa.

  1. Verifica que la clave se haya cargado correctamente consultando las huellas digitales almacenadas en el agente:
ssh-add -l
  1. Prueba la conexión forzando el uso exclusivo de la clave pública recién cargada, ignorando cualquier otro parámetro predeterminado:
ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes usuario@tu-servidor-ip

Método 4: Auditoría y Modificación de la Configuración del Demonio SSH (sshd_config)

Si los permisos y las claves son correctos pero el servidor sigue rechazando la conexión, debemos revisar las políticas de seguridad globales del archivo de configuración del demonio SSH.

  1. Abre el archivo de configuración principal utilizando un editor de texto con privilegios de superusuario:
sudo nano /etc/ssh/sshd_config
  1. Busca y valida que las siguientes directivas estén descomentadas y configuradas con los valores óptimos:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes

(Mantén temporalmente PasswordAuthentication yes para asegurarte un método de respaldo en caso de que necesites entrar vía contraseña mientras depuras).

  1. Guarda los cambios y verifica que la sintaxis del archivo de configuración esté libre de errores ejecutando la herramienta de validación de OpenSSH:
sudo sshd -t
  1. Si la validación no arroja errores, reinicia el servicio SSH para aplicar las nuevas directivas de manera inmediata:
sudo systemctl restart ssh

O en sistemas basados en distribuciones enterprise (RHEL/CentOS):

sudo systemctl restart sshd

Conclusión y Buenas Prácticas

El error Permission denied (publickey) en Linux deja de ser un obstáculo insalvable cuando se aborda mediante un enfoque metódico que analiza la trilogía fundamental: permisos del sistema de archivos, gestión correcta del agente SSH y directivas del demonio en el servidor. Al seguir rigurosamente los pasos detallados en esta guía, no solo habrás recuperado el acceso a tu entorno remoto, sino que habrás endurecido la postura de seguridad general de tu infraestructura, garantizando conexiones cifradas estables, eficientes y libres de fallos de autenticación futuros.

Ver todas las guías de Linux →