SSH: Permission denied (publickey) — causas y soluciones

Te pasa a las 2 de la mañana, tienes que acceder urgente a un servidor y te aparece esto:

victor@servidor: Permission denied (publickey).

Frustrante. Y encima el error no te dice nada útil. En este post te explico las causas más comunes y cómo solucionarlas paso a paso, de las más frecuentes a las más raras.

Paso 1: Activa el modo verbose para entender qué pasa

Lo primero siempre es ver qué está fallando realmente. Añade -v (o -vvv para más detalle) a tu comando SSH:

# Modo verbose básico
ssh -v victor@servidor.com

# Modo verbose máximo (el más útil para depurar)
ssh -vvv victor@servidor.com

Busca en la salida líneas como estas — te dirán exactamente dónde falla:

debug1: Offering public key: /home/victor/.ssh/id_ed25519
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

Causa 1: Los permisos de ~/.ssh están mal

Esta es la causa más frecuente y la más tonta. SSH rechaza las claves si los permisos del directorio o los archivos son demasiado permisivos. Lo compruebo lo primero siempre:

# Verificar permisos actuales
ls -la ~/.ssh/

# Los permisos correctos son:
# drwx------ (700) para el directorio .ssh
# -rw------- (600) para la clave privada
# -rw-r--r-- (644) para la clave pública
# -rw------- (600) para authorized_keys

# Corregirlos de una vez
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
chmod 600 ~/.ssh/authorized_keys

En el servidor también hay que verificarlo:

ls -la ~/.ssh/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Causa 2: La clave pública no está en authorized_keys del servidor

Puede parecer obvio, pero pasa más de lo que crees — especialmente cuando hay varios usuarios o se ha regenerado la clave. Verifica que tu clave pública está en el servidor:

# En el servidor, ver el contenido de authorized_keys
cat ~/.ssh/authorized_keys

# En tu máquina local, ver tu clave pública
cat ~/.ssh/id_ed25519.pub

# Deben coincidir. Si no está, añádela manualmente:
cat ~/.ssh/id_ed25519.pub | ssh usuario@servidor "cat >> ~/.ssh/authorized_keys"

Causa 3: SSH no está usando la clave correcta

Si tienes varias claves, SSH puede estar intentando usar la equivocada. Especifica explícitamente cuál usar:

# Especificar la clave manualmente
ssh -i ~/.ssh/id_ed25519 victor@servidor.com

# Ver qué claves está intentando usar
ssh -vvv victor@servidor.com 2>&1 | grep "Offering"

La solución definitiva es configurar el archivo ~/.ssh/config para que cada servidor use su clave correspondiente:

Host servidor-prod
    HostName servidor.com
    User victor
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes   # importante: fuerza a usar SOLO esta clave

Causa 4: La configuración del servidor no permite autenticación por clave

Si tienes acceso al servidor (por ejemplo por consola o VNC), verifica la configuración de SSH:

# Ver configuración SSH del servidor
sudo grep -E "PubkeyAuthentication|AuthorizedKeysFile|PasswordAuthentication" /etc/ssh/sshd_config

Debe aparecer así:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

Si PubkeyAuthentication está en no, cámbialo y reinicia SSH:

sudo nano /etc/ssh/sshd_config
# Cambia PubkeyAuthentication a yes

sudo systemctl restart sshd

Causa 5: El directorio home tiene permisos incorrectos

Menos conocida pero real: si el directorio home del usuario tiene permisos de escritura para otros, SSH ignora el authorized_keys por seguridad.

# Verificar permisos del home
ls -ld /home/victor/

# El home debe ser 755 o 750, nunca 777
chmod 755 /home/victor/

Causa 6: SELinux o AppArmor bloqueando el acceso

En sistemas con SELinux (CentOS, RHEL, Fedora) o AppArmor (Ubuntu), puede haber restricciones adicionales. Comprueba los logs:

# Ver logs de SSH en el servidor
sudo journalctl -u sshd --since "10 minutes ago"

# En sistemas con SELinux, verificar el contexto del archivo
ls -Z ~/.ssh/authorized_keys

# Restaurar contexto SELinux si está mal
restorecon -Rv ~/.ssh/

Causa 7: Estás usando el usuario incorrecto

Pasa más de lo que parece, especialmente en instancias cloud. Cada proveedor usa un usuario por defecto distinto:

Proveedor / SO	Usuario por defecto
AWS (Ubuntu)	ubuntu
AWS (Amazon Linux)	ec2-user
GCP (Debian/Ubuntu)	tu usuario de Google
Azure	azureuser
DigitalOcean	root
Hetzner	root

# Probar con el usuario correcto
ssh ubuntu@servidor.com
ssh ec2-user@servidor.com
ssh azureuser@servidor.com

Checklist rápida: qué revisar cuando falla SSH

1. Ejecuta ssh -vvv y lee el output
2. Verifica permisos: chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519 && chmod 600 ~/.ssh/authorized_keys
3. Confirma que la clave pública está en ~/.ssh/authorized_keys del servidor
4. Prueba especificando la clave: ssh -i ~/.ssh/tu_clave usuario@servidor
5. Revisa /etc/ssh/sshd_config en el servidor — PubkeyAuthentication yes
6. Comprueba permisos del home: chmod 755 /home/usuario
7. Revisa logs del servidor: journalctl -u sshd -n 50

Conclusión

El 90% de los casos de Permission denied (publickey) se resuelven con los tres primeros puntos del checklist: verbose para ver qué pasa, permisos correctos y verificar que la clave está en authorized_keys. El resto son casos más raros pero siguen el mismo patrón — buscar en los logs y revisar la configuración del servidor.

En el próximo post veremos Systemd: cómo gestionar servicios en Linux. ¿Tienes algún caso de SSH que no hayas podido resolver? Déjalo en los comentarios.