Solución a SSH: Permission denied (publickey)

Qué significa realmente Permission denied (publickey)

Permission denied (publickey) significa que el cliente envió una o varias claves públicas y el servidor no aceptó ninguna. La red funciona y sshd está activo: el rechazo se produce en el último paso de la autenticación. Si la sesión se cierra antes de ese punto, está ante connection refused o connection timed out, que requiere otro diagnóstico y otras comprobaciones. La solución no se basa en adivinanzas, porque ssh -v indica cuál de las cinco causas se aplica.

Las palabras entre paréntesis son los métodos que el servidor estaba dispuesto a aceptar. Permission denied (publickey) por sí solo significa que el inicio de sesión mediante contraseña está desactivado en ese servidor, por lo que no hay ninguna contraseña alternativa. Permission denied (publickey,password) significa que las contraseñas estaban disponibles y que también falló esa autenticación.

Un solo mensaje engloba cinco fallos distintos y es deliberadamente poco específico. Un servidor que respondiera "no existe ese usuario" o "esa clave no está instalada" ayudaría a cualquiera que buscara cuentas válidas. Por tanto, no empiece a sustituir claves ni a editar archivos de configuración. Ejecute un comando, lea tres líneas de salida y reduzca las cinco causas posibles a una.

Ejecute primero ssh -v y lea tres líneas

Repita el comando que falló, añadiendo -v:

ssh -v deploy@203.0.113.10

Una ejecución resumida pero realista tiene este aspecto:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

Tres líneas contienen toda la información necesaria.

Authenticating to 203.0.113.10:22 as 'deploy' es el nombre de usuario que se utilizará realmente. No es el que pretendía usar, sino el que ssh obtuvo de la línea de comandos, de ~/.ssh/config o de su nombre de usuario local.

Authentications that can continue: publickey es la lista de métodos aceptados por el servidor, enviada antes de probar cualquier clave. Si publickey no aparece en esa primera lista, el servidor tiene desactivado el inicio de sesión con clave pública, por lo que ninguna clave funcionará.

Offering public key: ... es una línea por cada clave que su cliente envió realmente. Indica el archivo de origen y su huella digital SHA256. Si una clave no tiene una línea Offering, nunca se envió al servidor.

Ahora divida el problema en dos:

• No hay ninguna línea Offering public key para la clave que espera. El problema está en su equipo, porque el servidor no ha recibido la clave.
• Se ofrece la clave y vuelve a aparecer Authentications that can continue: publickey. El servidor recibió esa clave y la rechazó, por lo que el problema está en el servidor.

Las causas siguientes están ordenadas según la frecuencia con que resultan ser la respuesta.

Causa 1: se conecta con el nombre de usuario incorrecto

La causa más habitual también es la menos interesante. sshd, el daemon del servidor SSH (secure shell), nunca indica que una cuenta no existe. Ejecuta todo el intercambio con un nombre de usuario inventado y rechaza la conexión al final con el mismo mensaje, porque revelar nombres de cuentas válidos ayuda a un atacante. Un error tipográfico en el nombre de usuario tiene exactamente el mismo aspecto que una clave dañada.

Compruebe la línea Authenticating to ... as antes de hacer cualquier otra cosa. Si contiene el nombre de inicio de sesión de su equipo portátil en lugar de la cuenta del servidor, omitió el nombre de usuario en el comando.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

La cuenta predeterminada depende de la imagen que prepara su proveedor. En agosto de 2026, las imágenes de Ubuntu para la nube suelen incluir una cuenta ubuntu, las imágenes de Debian incluyen debian o admin, Rocky Linux y AlmaLinux incluyen rocky y almalinux, y muchos proveedores de VPS instalan directamente su clave en root. El panel de control del proveedor registra la cuenta que creó. Ningún comando ejecutado desde fuera del servidor puede consultarlo.

Un bloque Host en ~/.ssh/config también establece el nombre de usuario y tiene prioridad sobre el nombre de inicio de sesión local:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Si creó la cuenta usted mismo y después no pudo iniciar sesión con ella, probablemente la clave se instaló para el usuario predeterminado de la imagen y nunca se copió a la nueva cuenta. Ese paso forma parte de los primeros diez minutos en un VPS nuevo y es fácil omitirlo.

Causa 2: la clave que cree estar enviando no es la que se envía

De forma predeterminada, ssh ofrece sólo las claves que contiene ssh-agent y un conjunto fijo de nombres de archivo en ~/.ssh: id_ed25519, id_ecdsa, id_rsa y las variantes de hardware y DSA de esos nombres. Una clave guardada como ~/.ssh/vps-prod no es visible para ssh hasta que la especifica. Por eso la salida detallada no muestra ninguna línea Offering public key.

Especifique el archivo y evite que las claves del agente ocupen su lugar:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

-i por sí solo no basta cuando el agente contiene claves, porque ssh sigue ofreciendo primero las claves del agente y deja el archivo especificado para el final. Esto es importante porque el servidor cuenta cada clave rechazada para MaxAuthTries, cuyo valor predeterminado es 6. Un agente que contiene siete claves puede agotar el límite antes de que se pruebe la clave correcta. Entonces el mensaje cambia a:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

Si aparece ese mensaje, el servidor cerró la sesión antes de que se probara la clave correcta. Este problema se trata en demasiados fallos de autenticación. IdentitiesOnly=yes limita el intento al archivo que indicó. Muestre las claves que mantiene el agente con ssh-add -l y vacíelo con ssh-add -D si ha acumulado claves antiguas durante años. Después, guarde la configuración para que el siguiente inicio de sesión no dependa de recordar flags:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Existe otra causa del lado del cliente. ssh se niega a usar una clave privada que otras cuentas de su propia máquina puedan leer. Muestra una advertencia y después ignora la clave. Por tanto, la clave nunca se ofrece y el servidor nunca la recibe:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod corrige el problema. Mover una clave mediante una memoria USB o un recurso compartido de Windows es la forma habitual de perder los permisos. La ubicación de las claves y los nombres que debe usar se explican en Conceptos básicos de la gestión de claves SSH.

Causa 3: la clave pública nunca llegó a authorized_keys

Si ssh -v muestra que la clave se envía y el servidor la sigue rechazando, la siguiente pregunta es si esa clave está en el archivo authorized_keys de la cuenta. Abra la consola de su proveedor para comprobarlo, porque no puede iniciar sesión mediante SSH para revisarlo.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

ssh-keygen -lf sobre un archivo authorized_keys muestra una huella digital por entrada:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

Compare esas huellas con la huella de la línea Offering public key. Si no aparece en la lista, la clave no está instalada en esa cuenta, independientemente de lo que recuerde haber hecho.

Hay cuatro causas habituales:

• Pegó la clave privada en lugar del archivo .pub. Una línea de clave pública empieza por ssh-ed25519 o ssh-rsa. Una clave privada empieza por -----BEGIN OPENSSH PRIVATE KEY-----.
• El contenido pegado se dividió en varias líneas. Cada entrada debe ocupar exactamente una línea. Por tanto, una clave dividida se interpreta como varias entradas dañadas y no coincide con ninguna.
• La clave se guardó en /root/.ssh/authorized_keys, pero inicia sesión como deploy, o al contrario. El archivo es específico de cada cuenta y no existe un archivo compartido.
• El cuadro «añadir mi clave» del proveedor la escribió sólo en el usuario predeterminado de la imagen. Por eso, la cuenta que creó después tiene un directorio .ssh vacío.

La forma segura de añadir una clave desde la consola, como root, es la siguiente:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Ejecute sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys de nuevo después. La nueva huella debería aparecer en la lista. Desde una máquina que todavía pueda iniciar sesión con contraseña, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 realiza el mismo trabajo y establece los permisos correctamente.

Causa 4: por qué sshd ignora authorized_keys cuando los permisos son demasiado abiertos

StrictModes yes es el valor predeterminado de sshd. Con esta configuración, sshd se niega a leer authorized_keys si cualquier usuario que no sea el propietario puede escribir en ese archivo, en el directorio .ssh o en el directorio principal de la cuenta. El motivo es directo: si el grupo o cualquier otro usuario puede escribir en el directorio principal, cualquier cuenta con ese acceso puede reemplazar authorized_keys y hacerse con el inicio de sesión. sshd trata una ruta que no considera confiable como si no existiera ninguna clave.

El cliente muestra el mensaje genérico Permission denied. El registro del servidor indica el motivo real:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

o, cuando el problema está en el propio archivo:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

Lo que acepta sshd:

• El directorio principal: no debe permitir escritura al grupo ni a cualquier otro usuario. 755, 750 y 700 son válidos. 775 y 777 no son válidos.
• ~/.ssh: modo 700.
• ~/.ssh/authorized_keys: modo 600.
• Propietario: los tres deben pertenecer a la cuenta con la que inicia sesión, no a root.

La propiedad es tan importante como el modo. Un archivo dentro de /home/deploy/.ssh que pertenezca a root falla la misma comprobación. Esto ocurre cuando se crea con sudo nano y se olvida devolverlo a su propietario. Corrija ambos aspectos a la vez:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

El último comando muestra el resultado. El directorio principal debe tener drwxr-xr-x o permisos más restrictivos, y drwx------ debe aplicarse a .ssh. Si esas cadenas todavía no son claras, consulte cómo leer una cadena de permisos como drwxr-xr-x antes de cambiar los modos en un servidor en producción.

En Rocky Linux y AlmaLinux, incluya SELinux (security-enhanced Linux) entre las posibles causas. Un directorio .ssh creado mediante un procedimiento inusual puede tener una etiqueta de archivo incorrecta. Por eso, sshd puede recibir una denegación de acceso de lectura aunque los modos sean correctos. sudo restorecon -Rv /home/deploy/.ssh restaura las etiquetas y sudo ausearch -m avc -ts recent muestra si SELinux fue el componente que rechazó el acceso.

Causa 5: sshd está configurado para rechazar la conexión

Leer /etc/ssh/sshd_config no basta en un sistema Ubuntu o Debian actual. Ese archivo comienza con Include /etc/ssh/sshd_config.d/*.conf, y OpenSSH conserva el primer valor que encuentra para cada configuración. Por tanto, un archivo adicional como 50-cloud-init.conf se lee antes y prevalece sobre cualquier valor que edite más abajo en el archivo principal. Por eso una modificación puede parecer correcta y no cambiar absolutamente nada.

Pida a sshd la configuración que realmente está utilizando:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

Una respuesta correcta tiene este aspecto:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Esto es lo que debe buscar en su propia salida:

• pubkeyauthentication no. Nunca se aceptará ninguna clave. Esto también aparece en ssh -v como una primera lista de Authentications that can continue: sin ningún publickey.
• authorizedkeysfile apunta a otra ubicación, por ejemplo, /etc/ssh/authorized_keys/%u. En ese caso, el archivo del directorio personal se ignora por completo y las reglas de permisos de la causa 4 se aplican a la nueva ruta.
• allowusers o allowgroups están presentes. Las cuentas que no aparezcan en la lista se rechazan exactamente con este error y sin explicación. denyusers y denygroups hacen lo contrario.
• permitrootlogin no mientras intenta iniciar sesión como root. prohibit-password es la configuración intermedia adecuada: root puede usar una clave, pero no una contraseña.

Los bloques Match no aparecen en un sshd -T simple, porque su resultado depende de quién se conecta. Consulte una conexión específica:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Hay otra configuración que afecta a las claves antiguas. OpenSSH 8.8 dejó de aceptar de forma predeterminada las firmas SHA-1 (ssh-rsa), por lo que una clave RSA que funcionó durante años puede dejar de funcionar justo después de actualizar el servidor. El cliente lo indica claramente:

debug1: send_pubkey_test: no mutual signature algorithm

La solución correcta es crear una clave nueva: ssh-keygen -t ed25519 -C "deploy@vps-prod", y después instalar el archivo .pub como se muestra arriba. Configurar PubkeyAcceptedAlgorithms +ssh-rsa en el servidor vuelve a habilitar las firmas antiguas y permite acceder al servidor hoy, pero debe considerarlo una medida temporal para recuperar el acceso, no el final del trabajo. El resto de la configuración del servidor que conviene revisar se encuentra en reforzar la seguridad del servidor SSH en un VPS.

Cómo demostrar que una clave privada coincide con la clave pública instalada

Gran parte de la incertidumbre de este error se debe a no saber si dos archivos forman un par. Un comando lo confirma:

ssh-keygen -y -f ~/.ssh/vps-prod

Muestra la clave pública derivada de la clave privada. Nunca lee el archivo .pub que está junto a ella, por lo que indica cuál es realmente la clave privada, no lo que afirma un archivo .pub obsoleto. Si la clave tiene una frase de contraseña, el comando la solicita. Esto también demuestra que todavía conoce la frase de contraseña.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

El primero muestra la huella digital de un archivo de clave pública. El segundo muestra las huellas digitales que conserva su agente. Compare cuatro vistas de la misma cadena: la huella digital de la línea Offering public key de ssh -v, la huella digital de su archivo .pub, las huellas digitales de ssh-keygen -lf en authorized_keys del servidor y la huella digital del registro del servidor. El punto en el que dejan de coincidir identifica el origen del problema.

Leer el registro del servidor mientras falla el inicio de sesión

El cliente no recibe ninguna información útil de forma intencionada. El servidor escribe el motivo real. Inicie el seguimiento del registro en la sesión de consola y, después, ejecute desde su portátil el comando ssh que falla.

sudo journalctl -u ssh -f

Ubuntu 24.04 no instala rsyslog de forma predeterminada, por lo que /var/log/auth.log puede no existir allí. En Rocky Linux y AlmaLinux, la unidad se llama sshd y los mismos registros también se escriben en /var/log/secure.

Establezca LogLevel VERBOSE en la configuración de sshd y vuelva a cargar el servicio. A partir de ese momento, cada intento registra la huella digital que el servidor recibió realmente:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

Esa línea indica en qué lado está el problema. Si reconoce la huella digital, la clave llegó al servidor y este la rechazó. Revise las causas 3, 4 y 5. Si no reconoce la huella digital, el cliente envió una clave distinta de la prevista. Vuelva a la causa 2.

Si el registro sigue sin ser claro, ejecute un segundo sshd en otro puerto en modo de depuración. Se mantiene en primer plano, atiende una conexión, muestra el razonamiento y después termina:

sudo /usr/sbin/sshd -ddd -p 2222

Desde la sesión de consola del mismo servidor, conéctese mediante la dirección de loopback:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

El uso de 127.0.0.1 evita que el firewall intervenga en la prueba. La salida de depuración indica el archivo que abrió, la huella digital que comparó y el rechazo exacto, incluidas líneas como Authentication refused: bad ownership or modes for directory /home/deploy. Pulse Ctrl+C cuando haya identificado la causa. El sshd real del puerto 22 no se modifica durante la prueba.

Cómo evitar quedarse fuera del servidor

Cada paso que modifique la configuración del servidor necesita una vía de acceso que no dependa de SSH. Configúrela mientras SSH todavía funcione, no después de que falle.

1. Abra la consola de su proveedor mediante serie o VNC (virtual network computing) y confirme que puede iniciar sesión allí.
2. Asegúrese de conocer una contraseña local válida para una cuenta con sudo. Si no tiene ninguna, restablezca primero la contraseña de root desde la consola del proveedor.
3. Mantenga abierta la sesión SSH actual. Una sesión abierta sobrevive a systemctl restart ssh, por lo que sigue siendo una vía de acceso si la nueva configuración es incorrecta.
4. Compruebe la sintaxis antes de reiniciar: sudo sshd -t no muestra nada cuando el archivo es válido y muestra el archivo y el número de línea cuando no lo es.
5. Abra un segundo terminal e inicie una sesión nueva antes de cerrar la primera. Una configuración incorrecta impide nuevos inicios de sesión y no afecta a los existentes, por lo que la sesión actual no puede confirmar si el cambio funcionó.

Reinicie con sudo systemctl restart ssh en Debian y Ubuntu, o con sudo systemctl restart sshd en Rocky Linux y AlmaLinux. En Ubuntu 24.04, sshd se inicia desde una unidad de socket, por lo que un cambio en Port o ListenAddress también requiere sudo systemctl restart ssh.socket para que surta efecto.

FAQ

¿Por qué aparece Permission denied (publickey) cuando la misma clave funciona en otro servidor?

Porque la clave es válida y el problema está en algún elemento relacionado. Ejecute ssh -v y busque la línea Offering public key. Si la clave no aparece, ssh nunca la envió: el archivo no está en ~/.ssh con un nombre predeterminado y tampoco está cargado en el agente. Añádala con -i /path/to/key -o IdentitiesOnly=yes. Si la clave aparece y el servidor sigue rechazándola, esa clave no está en el archivo authorized_keys de la cuenta, la ruta hasta ese archivo permite escritura al grupo o el usuario está bloqueado en la configuración de sshd. El registro del servidor permite distinguir estos casos.

¿Cómo puedo ver qué clave está enviando realmente SSH?

ssh -v host muestra una línea debug1: Offering public key: por cada clave. Cada línea indica el archivo de origen y una huella SHA256. ssh-add -l muestra las huellas que tiene el agente. ssh-keygen -lf ~/.ssh/id_ed25519.pub muestra la huella de un archivo de clave concreto y ssh-keygen -y -f ~/.ssh/id_ed25519 muestra la clave pública que se obtiene realmente de una clave privada. Para que el inicio de sesión funcione, la huella de la línea Offering también debe aparecer en la salida de ssh-keygen -lf ejecutado contra el archivo authorized_keys del servidor.

¿Por qué sshd ignora mi archivo authorized_keys?

Porque StrictModes está activado de forma predeterminada y el archivo, el directorio .ssh o el directorio personal permiten escritura al grupo o a otros usuarios, o pertenecen a una cuenta incorrecta. sshd no confía en una ruta que otra persona pueda modificar, por lo que se comporta como si no existiera ninguna clave. Establezca el directorio personal en 755 o con permisos más restrictivos, .ssh en 700 y authorized_keys en 600. Los tres elementos deben pertenecer a la cuenta de inicio de sesión. Con LogLevel VERBOSE, el servidor registra Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

Mi clave dejó de funcionar justo después de actualizar el servidor. ¿Qué cambió?

Si es una clave RSA, lo más probable es que haya cambiado el uso de SHA-1. OpenSSH 8.8 desactivó de forma predeterminada las firmas SHA-1 ssh-rsa, por lo que ahora se rechaza una clave que sólo puede firmar de esa forma. La salida detallada del cliente muestra debug1: send_pubkey_test: no mutual signature algorithm. Genere una clave moderna con ssh-keygen -t ed25519 e instale su archivo .pub. Si necesita recuperar el acceso de inmediato, PubkeyAcceptedAlgorithms +ssh-rsa en el servidor vuelve a activar las firmas antiguas. Retire esa línea cuando la nueva clave funcione.

Edité sshd_config y ahora no puedo iniciar sesión. ¿Cómo recupero el acceso?

Use la consola de su proveedor. Esta consola no pasa por SSH. Inicie sesión con una contraseña local, ejecute sudo sshd -t para ver el error de sintaxis y su número de línea, deshaga el cambio y reinicie el servicio. Después, compruebe sudo sshd -T para confirmar los valores activos, porque un archivo de /etc/ssh/sshd_config.d/ puede estar sobrescribiendo la configuración principal. Si no tiene una contraseña local, restablezca primero la contraseña de root desde la consola y repare después el archivo.