¿Cómo arreglo SSH permission denied (publickey) en Ubuntu?

Revisa el lado del servidor con journalctl -u ssh -n 50, confirma que tu clave pública está en ~/.ssh/authorized_keys del usuario objetivo, y asegúrate de que los permisos son 700 en ~/.ssh y 600 en authorized_keys y la clave privada.

¿Por qué ssh -i miclave sigue fallando?

Tres razones habituales: los permisos de la clave privada son demasiado abiertos y OpenSSH se niega a cargarla, el servidor usa OpenSSH 8.8+ que deshabilitó ssh-rsa (firmas SHA-1), o la clave no está en los authorized_keys del usuario correcto.

¿Cómo añado mi clave pública a un servidor?

Ejecuta ssh-copy-id user@host — añade tu clave pública a ~/.ssh/authorized_keys con los permisos correctos. Si el login por contraseña ya está deshabilitado, hazlo desde una consola a la que aún tengas acceso.

SSH Permission denied (publickey): la solución real // mrsaynothing

Q: ¿Por qué SSH dice Permission denied (publickey)?

Significa que cada clave que el cliente ofreció fue rechazada por el servidor, y que la autenticación por contraseña o keyboard-interactive no se intentó o no está permitida. Es un veredicto de negociación sobre tus claves — no una contraseña mal escrita.

A las 02:10 un despliegue murió en una línea que he tecleado mil veces: ssh deploy@staging → Permission denied (publickey). La clave estaba bien. La oferta, no.

TL;DR: Permission denied (publickey) significa que cada clave que el cliente ofreció fue rechazada por el servidor — un veredicto de negociación, no una contraseña mal escrita. Diagnostica con ssh -vvv (qué claves se ofrecieron) y el log del servidor journalctl -u ssh (qué claves se rechazaron, y por qué). Luego corrige una de las cuatro causas: usuario equivocado, clave ausente de authorized_keys, permisos demasiado abiertos, o una clave ssh-rsa rechazada por OpenSSH 8.8+. ssh-copy-id evita la mayoría de recaídas.

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

El error es un veredicto, no una pista: todo lo que había en la oferta fue rechazado.

¿Por qué SSH dice “Permission denied (publickey)“?

La autenticación de clave pública es una negociación de oferta y rechazo. El cliente propone cada clave que puede encontrar — identidades de tu agente, tu ~/.ssh/config, nombres de archivo por defecto (id_ed25519, id_rsa) y todo lo que pases con -i. El servidor comprueba cada oferta contra los ~/.ssh/authorized_keys de la cuenta objetivo. Cuando ninguna coincide, y la autenticación por contraseña está deshabilitada o agotada, el cliente imprime la línea que todo ingeniero devops tiene memorizada.

Dos hechos importan para depurar. Primero, el mensaje no dice qué usuario tocaste — la mitad de los casos son una clave perfectamente buena sentada en el authorized_keys de la cuenta equivocada. Segundo, el servidor ya te dijo por qué: sshd registra cada oferta rechazada. El stack trace que nadie pidió y todo el mundo necesita es -vvv.

¿Cómo veo qué clave ofrece SSH realmente?

ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
# debug1: Offering public key: /home/you/.ssh/id_ed25519 RSA-SHA256 (explicit)
# debug1: Authentications that can continue: publickey
# deploy@staging: Permission denied (publickey).

Lee tres líneas: Offering public key (lo que el cliente propuso), Authentications that can continue (lo que el servidor aún acepta — si password no aparece, ningún aviso de contraseña llegará jamás) y el veredicto final. Si tu clave nunca aparece en la lista de ofertas, el problema está en el cliente: una ruta -i equivocada, un IdentityFile olvidado en ~/.ssh/config, o un agente (ssh-add -l) sosteniendo una identidad obsoleta que responde primero.

¿Cuáles son las cuatro causas reales?

Causa	Pista	Arreglo
Usuario equivocado	La clave funciona con `root@host`, falla con `deploy@host`	La clave debe estar en los `~/.ssh/authorized_keys` de ese usuario
Clave no instalada	El log del servidor muestra `Failed publickey` en cada oferta	`ssh-copy-id user@host`
Permisos demasiado abiertos	Cliente: `WARNING: UNPROTECTED PRIVATE KEY FILE` — la clave se salta, nunca se ofrece	`chmod 700 ~/.ssh; chmod 600 ~/.ssh/*`
Clave `ssh-rsa` legada	Servidor con OpenSSH 8.8+; clave RSA antigua nunca aceptada	Regenerar como ed25519, o actualizar la clave

La causa de los permisos merece nota propia, porque OpenSSH la aplica con rigor: una clave privada legible por el grupo u otros es rechazada por el propio cliente y sale silenciosamente de la oferta. El arreglo son dos comandos:

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

La causa ssh-rsa tropieza con imágenes CI viejas y Raspberry Pis: OpenSSH 8.8 (publicada el 2021-10-01, openssh.com/txt/release-8.8) deshabilitó por defecto las firmas ssh-rsa — la variante basada en SHA-1. Según las notas de versión, “the ssh-rsa signature scheme is … disabled by default”. Una clave RSA generada en 2018 no está rota; su formato de firma simplemente ya no se habla. Generar una clave ed25519 (ssh-keygen -t ed25519) es la respuesta duradera, y las consolas de la nube te dan una consola serie cuando te dejas fuera a mitad del arreglo.

Si sshd se niega a arrancar mientras editas su configuración, esa es otra cacería — ver systemd service not starting.

¿Cómo veo por qué el servidor rechazó la clave?

El log del lado del servidor es el testigo honesto. En Ubuntu (systemd), sshd registra el veredicto de cada oferta:

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"
# sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:...
# sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:...

Un Failed publickey con una huella que no esperabas significa que el cliente ofreció otra clave distinta de la que creías — de vuelta al -vvv. Un Failed publickey con tu huella significa que la clave es correcta pero no está instalada para esa cuenta, o que los permisos del home en el lado del servidor están mal (la misma regla 700/600 aplica al ~/.ssh y ~/.ssh/authorized_keys del servidor).

¿Cómo instalo mi clave correctamente?

ssh-copy-id deploy@staging
# Number of key(s) added: 1
ssh -o BatchMode=yes deploy@staging 'echo ok'   # prueba no interactiva

ssh-copy-id añade tu clave pública a los authorized_keys de la cuenta objetivo con permisos sensatos — existe porque pegar a mano en authorized_keys falla justo lo suficiente, por un salto de línea final o un directorio que no existe. La prueba BatchMode es la real: desactiva todos los avisos, así que un éxito significa que la clave sola cargó el login. Una vez la clave funciona, scp y rsync heredan la misma autenticación gratis — la elección entre ellos es ancho de banda, no credenciales (rsync vs scp).

El triaje de 30 segundos

ssh -vvv user@host 2>&1 | grep -i offering      # 1. ¿qué claves se ofrecieron?
journalctl -u ssh -n 50 | grep -i publickey     # 2. ¿por qué se rechazaron?
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. ¿700 / 600?
ssh-copy-id user@host                           # 4. instalar, y verificar con BatchMode

Permission denied (publickey) es un resultado de negociación, no un aviso de contraseña — el servidor rechazó cada clave de la oferta, y su log ya sabe por qué.

Ejecuta los cuatro comandos en orden y el fallo deja de ser misterioso: uno de ellos nombra al culpable todas las veces. El mío era una identidad de agente obsoleta respondiendo antes que la clave correcta — ssh-add -d, y el despliegue se puso verde a las 02:31.

SSH Permission denied (publickey): la solución real