Permission denied (publickey).

Va precedido de `user@host:`. La lista entre paréntesis muestra los métodos que el servidor aún permite, por ejemplo `(publickey,password)` o `(publickey,gssapi-keyex,gssapi-with-mic)`.

Qué significa

La conexión SSH y la verificación del host funcionaron, pero el servidor no aceptó ninguna de las claves públicas que ofreció el cliente, y la autenticación por clave pública es el único método que permite (la lista entre paréntesis). El cliente nunca llega a saber por qué se rechazó una clave: ese motivo solo figura en el registro del servidor. En GitHub, GitLab y Bitbucket, el mismo mensaje significa que ninguna de tus claves está registrada en la cuenta (o como clave de despliegue) para ese repositorio.

Por qué ocurre

• No se ofrece la clave correcta

  frecuente

  La clave no está en el agente, ni en una ruta predeterminada (`~/.ssh/id_ed25519`, `id_ecdsa`, `id_rsa`), ni se indica con `-i` o `IdentityFile`. Con muchas claves en el agente, el servidor puede desconectar (MaxAuthTries) antes de que se pruebe la correcta.

• La clave no está en el authorized_keys de ese usuario

  frecuente

  Instalada para otro usuario u otro host, eliminada durante una reinstalación o (en el alojamiento Git) añadida a una cuenta distinta de la que tiene acceso al repositorio.

• sshd ignora authorized_keys por los permisos

  ocasional

  Con `StrictModes yes` (el valor predeterminado), si el directorio personal, `~/.ssh` o `authorized_keys` tienen permiso de escritura para el grupo o para todos, sshd rechaza el archivo. El registro del servidor dice «Authentication refused: bad ownership or modes».

• No se acepta el algoritmo de firma de la clave

  ocasional

  Los servidores OpenSSH 8.8+ rechazan las claves RSA que los clientes y bibliotecas antiguos usan con el algoritmo `ssh-rsa` basado en SHA-1; OpenSSH 10 elimina por completo las claves DSA. El servidor registra «not in PubkeyAcceptedAlgorithms».

• Nombre de usuario remoto incorrecto

  ocasional

  `ssh server` inicia sesión con tu nombre de usuario local. Las imágenes de nube esperan `ubuntu`, `ec2-user` o `admin`; el alojamiento Git siempre espera `git@`.

Cómo solucionarlo

1. 1.

   Ver qué claves se ofrecen

   `ssh -v` enumera cada clave que ofrece el cliente y si el servidor la aceptó; `ssh -G` muestra el usuario y los archivos de identidad efectivos después de aplicar toda la configuración.

   ssh -v deploy@server.example.com 2>&1 | grep -E "Offering|Server accepts|Authentications that can continue|send_pubkey_test"
   ssh-add -l                                  # keys the agent offers
   ssh -G deploy@server.example.com | grep -E "^(user|identityfile|identitiesonly) "

2. 2.

   Fijar la identidad para cada host

   `IdentityFile` junto con `IdentitiesOnly yes` ofrece exactamente una clave y evita «Too many authentication failures» con agentes que guardan muchas claves.

   # ~/.ssh/config
   Host server.example.com
     User deploy
     IdentityFile ~/.ssh/deploy_ed25519
     IdentitiesOnly yes

3. 3.

   Corregir el lado del servidor y leer su registro

   Instala la clave pública para el usuario correcto con permisos estrictos y busca en el registro de sshd el motivo concreto del rechazo.

   # On the server: install the key and fix modes (sshd ignores keys in group/world-writable paths)
   install -d -m 700 ~/.ssh && cat deploy_ed25519.pub >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys
   sudo journalctl -u ssh --since "10 min ago" | grep -E "Authentication refused|not in PubkeyAccepted|Failed publickey"

← Explorar toda la base de datos de errores de firma