El error Permission denied (publickey). es uno de los problemas SSH más frustrantes de diagnosticar porque puede tener múltiples causas, y el mensaje de error en sí proporciona muy poca información sobre lo que salió mal. Este artículo se enfoca en una causa particularmente difícil — directorios home cifrados — y también cubre las otras causas comunes y sus soluciones.

El Problema

Configuraste la autenticación por clave SSH correctamente en tu servidor Ubuntu. Todo funciona perfectamente — hasta que reinicias el servidor. Después del reinicio, obtienes:

Permission denied (publickey).

Accedes al servidor por consola, y todo parece estar bien — las claves están en el lugar correcto, los permisos se ven correctos. Intentas SSH de nuevo y funciona. Reinicias el servidor o el servicio SSH, y el error vuelve.

Este comportamiento intermitente es el síntoma clave que apunta a un directorio home cifrado como la causa raíz.

Por Qué los Directorios Home Cifrados Rompen la Autenticación SSH por Clave

Cuando instalas Ubuntu y eliges cifrar tu directorio home, el sistema usa eCryptfs para cifrar ~/.Private y montarlo en tu directorio home al iniciar sesión. Esto es lo que sucede:

  1. Antes del inicio de sesión: El contenido de tu directorio home está cifrado. El demonio SSH intenta leer ~/.ssh/authorized_keys pero no puede porque el directorio está cifrado.
  2. Durante el inicio de sesión por consola: Ingresas tu contraseña, lo que activa el descifrado y montaje de tu directorio home.
  3. Después del inicio de sesión: ~/.ssh/authorized_keys ahora es legible, así que la autenticación por clave SSH funciona.

Esto crea el patrón confuso donde las claves SSH funcionan después de iniciar sesión manualmente pero fallan después de un reinicio.

Dato clave: Los servidores en la nube (AWS, Azure, DigitalOcean, etc.) no cifran los directorios home por defecto, por lo que este problema típicamente solo afecta a servidores que instalaste tú mismo donde elegiste la opción de cifrado.

Diagnóstico del Problema

Paso 1: Habilitar Salida SSH Detallada

Conéctate con máxima verbosidad para ver exactamente dónde falla la autenticación:

ssh -vvv usuario@tu-servidor

Busca líneas como:

debug1: Offering public key: /home/tuusuario/.ssh/id_ed25519
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

La respuesta type 51 significa que el servidor rechazó la clave.

Paso 2: Revisar Logs del Servidor

En el servidor (accedido por consola), examina el log de autenticación:

sudo tail -50 /var/log/auth.log

Para problemas de directorio home cifrado, podrías ver:

sshd[1234]: Could not open authorized keys '/home/usuario/.ssh/authorized_keys': No such file or directory

Este mensaje aparece porque el directorio cifrado se ve vacío para el demonio SSH.

Paso 3: Verificar el Cifrado del Directorio Home

Comprueba si tu directorio home está cifrado:

ls -la /home/

Si ves un directorio .ecryptfs o .Private, tu directorio home usa cifrado:

ls -la /home/usuario/
# Si está cifrado y no montado, podrías ver:
# .ecryptfs  .Private  Access-Your-Private-Data.desktop  README.txt

También puedes verificar:

mount | grep ecryptfs

Solución 1: Almacenar Claves SSH Fuera del Directorio Home Cifrado (Recomendado)

El mejor enfoque es configurar SSH para leer las claves autorizadas desde una ubicación fuera del directorio home cifrado.

Crear el Directorio Alternativo de Claves

sudo mkdir -p /etc/ssh/authorized_keys

Copiar Tus Claves Autorizadas

sudo cp ~/.ssh/authorized_keys /etc/ssh/authorized_keys/$USER
sudo chown root:root /etc/ssh/authorized_keys/$USER
sudo chmod 644 /etc/ssh/authorized_keys/$USER

Actualizar la Configuración SSH

Edita la configuración del demonio SSH:

sudo nano /etc/ssh/sshd_config

Busca la directiva AuthorizedKeysFile y cámbiala a:

AuthorizedKeysFile /etc/ssh/authorized_keys/%u

El %u se reemplaza por el nombre de usuario durante la autenticación.

Reiniciar SSH

sudo systemctl restart sshd

Probar la Configuración

Desde tu máquina local:

ssh usuario@tu-servidor

Esto debería funcionar incluso después de un reinicio porque /etc/ssh/authorized_keys/ no está dentro del directorio home cifrado.

Importante: Cuando agregues nuevas claves SSH en el futuro, necesitas agregarlas a /etc/ssh/authorized_keys/usuario en lugar de ~/.ssh/authorized_keys.

Para un tutorial detallado de este enfoque, consulta: Cómo almacenar tu clave pública SSH en un directorio diferente.

Solución 2: Descifrar el Directorio Home

Si decides que ya no necesitas el cifrado del directorio home:

# Asegúrate de estar conectado como el usuario
ecryptfs-migrate-home -u $USER

Advertencia: Haz una copia de seguridad de tus datos antes de intentar esto. El descifrado del directorio home puede fallar si no hay suficiente espacio en disco (necesitas aproximadamente el doble del espacio de tu directorio home temporalmente).

Otras Causas Comunes de ‘Permission denied (publickey)’

Si tu directorio home no está cifrado, el error probablemente viene de una de estas causas:

Permisos de Archivos Incorrectos

SSH es muy estricto con los permisos. Lo siguiente debe estar configurado correctamente:

# Directorio home: sin escritura para grupo/otros
chmod 755 ~
# o
chmod 700 ~

# Directorio .ssh: solo propietario
chmod 700 ~/.ssh

# authorized_keys: solo lectura/escritura del propietario
chmod 600 ~/.ssh/authorized_keys

# Clave privada (en tu cliente): solo lectura del propietario
chmod 600 ~/.ssh/id_ed25519

Clave No Agregada a authorized_keys

Verifica que tu clave pública esté en el archivo authorized_keys del servidor:

cat ~/.ssh/authorized_keys

Compárala con tu clave pública local:

# En tu máquina local
cat ~/.ssh/id_ed25519.pub

Agente SSH No Cargado

Si tu clave usa una frase de contraseña y el agente SSH no está ejecutándose:

# Iniciar el agente
eval "$(ssh-agent -s)"

# Agregar tu clave
ssh-add ~/.ssh/id_ed25519

Tipo de Clave Incorrecto

Los servidores más antiguos pueden no soportar tipos de clave más nuevos como Ed25519. Intenta generar una clave RSA:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_legacy
ssh-copy-id -i ~/.ssh/id_rsa_legacy.pub usuario@servidor

Configuración del Servidor Bloqueando la Autenticación por Clave Pública

Verifica que el servidor permita la autenticación por clave pública:

sudo grep -E "PubkeyAuthentication|AuthorizedKeysFile" /etc/ssh/sshd_config

Asegúrate de que:

PubkeyAuthentication yes

SELinux o AppArmor Bloqueando el Acceso

En sistemas con control de acceso obligatorio:

# Verificar SELinux
sudo restorecon -R ~/.ssh/

# Verificar AppArmor
sudo aa-status

Lista Rápida de Verificación

VerificaciónComando
Salida SSH detalladassh -vvv usuario@servidor
Log de autenticaciónsudo tail -50 /var/log/auth.log
¿Home cifrado?mount | grep ecryptfs
Permisos de .sshls -la ~/.ssh/
Contenido de authorized_keyscat ~/.ssh/authorized_keys
Configuración SSHsudo sshd -T | grep -i pubkey
Claves del agente SSHssh-add -l

Resumen

El error Permission denied (publickey) causado por directorios home cifrados es particularmente insidioso porque funciona de manera intermitente — la autenticación por clave SSH tiene éxito después de iniciar sesión manualmente pero falla después de un reinicio. La solución recomendada es almacenar las claves autorizadas fuera del directorio home cifrado actualizando AuthorizedKeysFile en sshd_config.

Para otras causas de este error, verifica sistemáticamente los permisos de archivos, confirma que la clave esté en authorized_keys, asegúrate de que el agente SSH esté ejecutándose y revisa el sshd_config del servidor. Usar ssh -vvv y revisar /var/log/auth.log casi siempre revelará la causa raíz.

Artículos Relacionados