Cómo corregir 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. La corrección no se basa en suposiciones, 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 con contraseña está desactivado en ese servidor, por lo que no hay ninguna contraseña como alternativa. Permission denied (publickey,password) significa que las contraseñas estaban disponibles y que también falló ese intento.

Un solo mensaje abarca cinco fallos distintos y es deliberadamente impreciso. 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 cambiar 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ó y añada -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 usará realmente. No es el que pretendía usar, sino el que ssh determinó a partir de la línea de comandos, de ~/.ssh/config o de su nombre de inicio de sesión 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 mediante clave pública, por lo que ninguna clave puede funcionar.

Offering public key: ... es una línea por cada clave que el cliente envió realmente. Indica el archivo de origen y su huella 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 esperada. El problema está en su equipo, porque el servidor no ha visto 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 la que resultan ser la respuesta.

Causa 1: se conecta con el nombre de usuario incorrecto

La causa más común 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álidas ayuda a un atacante. Un error tipográfico en el nombre de usuario produce exactamente el mismo resultado que una clave defectuosa.

Compruebe la línea Authenticating to ... as antes de hacer cualquier otra cosa. Si contiene el nombre de usuario de inicio de sesión de su 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 cloud de Ubuntu 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 de su proveedor indica qué cuenta 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 usuario 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 cuenta nueva. Ese paso forma parte de los primeros diez minutos en un VPS nuevo y es fácil omitirlo.

Causa 2: la clave que cree que está 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 para esa clave.

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

IdentitiesOnly=yes limita los intentos al archivo que especificó. Consulte las claves que contiene el agente con ssh-add -l y elimínelas 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 opciones:

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

Existe otra trampa en el cliente. ssh se niega a usar una clave privada que otras cuentas de su propio equipo 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 lo corrige. Mover una clave mediante una memoria USB o un recurso compartido de Windows es la forma habitual de que se pierdan los permisos. La ubicación de las claves y los nombres que deben tener 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 todavía la rechaza, 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 formas habituales de que falle:

• 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 texto pegado se dividió en varias líneas. Cada entrada debe ocupar exactamente una línea. Una clave dividida se interpreta como varias entradas dañadas y no coincide con nada.
• 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. No existe un archivo compartido.
• El cuadro «add my key» del proveedor sólo escribió la clave en el usuario predeterminado de la imagen. Por eso, la cuenta que creó después tiene el 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

Vuelva a ejecutar sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys después. La huella nueva debería aparecer en la lista. Desde una máquina que todavía pueda iniciar sesión con una contraseña, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 realiza el mismo trabajo y configura 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 personal de la cuenta. La razón es directa: si el grupo u otros usuarios pueden escribir en el directorio personal, cualquier cuenta con ese acceso puede reemplazar authorized_keys y tomar el control del inicio de sesión. sshd trata una ruta que no considera fiable como si no existiera ninguna clave.

El cliente muestra el mensaje genérico Permission denied. El registro del servidor indica la causa 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 sshd acepta:

• El directorio personal: no debe permitir escritura al grupo ni a otros usuarios. 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.

El propietario es tan importante como el modo. Un archivo dentro de /home/deploy/.ssh cuyo propietario sea root no supera la misma comprobación. Esto ocurre cuando se crea con sudo nano y después se olvida devolverlo a la cuenta correcta. Corrija ambas cosas 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 personal debe tener drwxr-xr-x o permisos más restrictivos, y drwx------ en .ssh. Si esas cadenas todavía no resultan claras, consulte cómo interpretar una cadena de permisos como drwxr-xr-x antes de cambiar los modos en un servidor en producción.

En Rocky Linux y AlmaLinux, añada SELinux (security-enhanced Linux) a la lista de posibles causas. Un directorio .ssh creado mediante un procedimiento inusual puede tener una etiqueta de archivo incorrecta. En ese caso, sshd no puede leerlo aunque los modos parezcan correctos. sudo restorecon -Rv /home/deploy/.ssh restaura las etiquetas y sudo ausearch -m avc -ts recent muestra si SELinux era el componente que denegaba el acceso.

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

Leer /etc/ssh/sshd_config no es suficiente 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 ajuste. Por tanto, un archivo drop-in como 50-cloud-init.conf se lee primero y prevalece sobre cualquier valor que edite más abajo en el archivo principal. Por eso una edición puede parecer correcta y no cambiar absolutamente nada.

Consulte a sshd para saber qué configuración está usando realmente:

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. También aparece en ssh -v como una lista inicial 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 de inicio 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. Cualquier cuenta que no figure en la lista se rechaza exactamente con este error y sin explicación. denyusers y denygroups hacen lo mismo a la inversa.
• permitrootlogin no mientras intenta iniciar sesión como root. prohibit-password es el ajuste intermedio útil: 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 otro ajuste que afecta a las claves antiguas. OpenSSH 8.8 dejó de aceptar firmas SHA-1 (ssh-rsa) de forma predeterminada, 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 mostró antes. Configurar PubkeyAcceptedAlgorithms +ssh-rsa en el servidor vuelve a habilitar las firmas antiguas y le permite acceder hoy, así que considérelo una forma de llegar al servidor, no como el final de la tarea. El resto de los ajustes 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

La mayor parte de las dudas en este error se debe a no saber si dos archivos forman un par. Un comando lo confirma:

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

Esto muestra la clave pública derivada de la clave privada. Nunca lee el archivo .pub que está junto a ella, por lo que indica qué contiene realmente la clave privada y 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 primer comando muestra la huella digital de un archivo de clave pública. El segundo muestra las huellas digitales que mantiene el agente. Compare cuatro representaciones 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 el authorized_keys del servidor y la huella digital del registro del servidor. El punto donde dejan de coincidir indica el origen del problema.

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

El cliente no recibe información útil a propósito. El servidor registra el motivo real. Inicie un 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 es posible que /var/log/auth.log no exista. En Rocky Linux y AlmaLinux, la unidad se llama sshd y los mismos registros también se guardan en /var/log/secure.

Establezca LogLevel VERBOSE en la configuración de sshd y recargue 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 y en modo de depuración. Se ejecuta en primer plano, atiende una conexión, muestra el razonamiento y después finaliza:

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 permanece intacto durante toda la prueba.

Cómo evitar bloquear el acceso al servidor

Cada paso que modifica la configuración del servidor debe tener una vía de acceso alternativa 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 (computación de red virtual) 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 sesión de nuevo antes de cerrar el primero. Una configuración incorrecta impide los nuevos inicios de sesión, pero no afecta a los existentes. Por eso, la sesión que mantiene abierta 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 entre en vigor.

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 ni está cargado en el agente, así que 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 sshd bloquea al usuario mediante su configuración. 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 digital SHA256. ssh-add -l muestra las huellas digitales que tiene el agente. ssh-keygen -lf ~/.ssh/id_ed25519.pub muestra la huella digital de un archivo de clave concreto y ssh-keygen -y -f ~/.ssh/id_ed25519 muestra la clave pública que se deriva realmente de una clave privada. Para que el inicio de sesión funcione, la huella digital de la línea Offering también debe aparecer en ssh-keygen -lf ejecutado contra el 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 cualquier usuario, o pertenecen a una cuenta incorrecta. sshd no confía en una ruta que otra persona pueda modificar, por lo que actúa como si no existiera ninguna clave. Establezca el directorio personal en 755 o con permisos más restrictivos, .ssh en 700, authorized_keys en 600, y haga que los tres pertenezcan 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 se deba al cambio relacionado con 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 acceso de inmediato, PubkeyAcceptedAlgorithms +ssh-rsa en el servidor vuelve a activar las firmas antiguas. Elimine 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.