Solucionar el error SSH "Permission denied (publickey)"

El intento de conexión se corta al cabo de un segundo, no llega ninguna petición de contraseña, solo una única línea: Permission denied (publickey). Este mensaje resulta tan incómodo justamente porque no revela nada a propósito. El servidor SSH no le dice a un posible atacante si el usuario existe, si la clave era incorrecta o si el archivo no se puede leer. Pero esa misma discreción te toca también a ti, cuando estás delante de la puerta con todo el derecho.

La buena noticia: las causas son limitadas, se pueden repasar en un orden fijo y, en la mayoría de los casos, se trata simplemente de los permisos de los archivos. Este artículo recorre las causas por orden de frecuencia, muestra para cada una el texto exacto que aparece en el log y explica cómo decidir en treinta segundos, con ssh -vvv, si el problema está en tu equipo o en el servidor.

El significado exacto del mensaje

El paréntesis final no es un adorno, es la información más importante de toda la línea. Ahí se indica qué métodos de autenticación sigue ofreciendo el servidor después del intento fallido:

Permission denied (publickey).
Permission denied (publickey,password).
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Si ahí solo pone publickey, el inicio de sesión con contraseña está desactivado en el servidor. Si password aparece en la lista, una autenticación por contraseña habría sido posible en principio, simplemente no se intentó o falló también. La variante con gssapi es típica de AlmaLinux, Rocky Linux y RHEL, donde el soporte de Kerberos viene compilado de fábrica.

Conviene distinguir este mensaje de otros que se le parecen, pero describen un problema completamente distinto:

• Permission denied, please try again. sin paréntesis es una contraseña incorrecta, no un problema de clave.
• Host key verification failed. afecta a la clave del servidor guardada en tu known_hosts, no a tu propia clave.
• Received disconnect from 203.0.113.7 port 22:2: Too many authentication failures significa que tu agente ha ofrecido demasiadas claves seguidas y que el servidor ha cortado al llegar a MaxAuthTries.
• Connection refused o un timeout son asuntos de red o de firewall. Si justo antes has estado tocando un firewall UFW o Fail2ban, empieza por ahí.

La bifurcación: leer bien ssh -vvv

Antes de cambiar nada, haz que te muestre el proceso completo. Las tres v son intencionadas, con una sola v faltan las líneas decisivas:

ssh -vvv deploy@203.0.113.7

La salida es larga, pero solo buscas cuatro puntos. Primero, el nombre de usuario con el que realmente se conecta:

debug1: Authenticating to 203.0.113.7:22 as 'deploy'

Segundo, qué claves tiene en cuenta el cliente y, tercero, cuál envía de verdad:

debug1: Will attempt key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk... agent
debug1: Offering public key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

Y cuarto, el mensaje de éxito, que en caso de fallo es precisamente el que falta:

debug1: Server accepts key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk...
debug1: Authenticated to 203.0.113.7 ([203.0.113.7]:22) using "publickey".

De ahí sale la bifurcación que te ahorra la mitad del diagnóstico:

• No aparece ningún Offering public key con tu clave. Entonces el problema está en tu equipo, la clave nunca llegó a enviarse. Salta a la causa 3.
• Aparece Offering public key, pero después vuelve a salir Authentications that can continue. Entonces el servidor ha visto tu clave y la ha rechazado. Son las causas 1, 2, 4, 5 y 6, todas del lado del servidor.
• Aparece send_pubkey_test: no mutual signature algorithm. Entonces el asunto es el tipo de clave, salta a la causa 7.

Otras dos líneas de la salida de depuración merecen un vistazo. debug3: no such identity: /home/tom/.ssh/id_rsa: No such file or directory es inofensiva, el cliente se limita a probar todos los nombres estándar. En cambio, Permissions 0644 for '/home/tom/.ssh/id_ed25519' are too open. sí es un hallazgo real, porque tu clave privada queda ignorada.

El lado del servidor: sshd -T y los logs

ssh -vvv muestra únicamente la perspectiva del cliente. El motivo del rechazo solo consta en el log del servidor. Si todavía tienes una sesión abierta o puedes entrar por la consola del área de cliente, mira ahí primero.

En Debian y Ubuntu el servicio se llama ssh, en AlmaLinux, Rocky Linux y RHEL se llama sshd. Es una trampa clásica al copiar comandos:

journalctl -u ssh -n 50 --no-pager      # Debian, Ubuntu
journalctl -u sshd -n 50 --no-pager     # AlmaLinux, Rocky, RHEL

El archivo de texto clásico ya no está en todas partes. Ubuntu 22.04 y 24.04 siguen manteniendo /var/log/auth.log en la instalación de servidor, porque ahí rsyslog viene incluido. Debian 12 y Debian 13 ya no instalan rsyslog en una instalación mínima, allí el archivo sencillamente no existe y todo acaba en el journal. En la familia Red Hat el archivo se llama /var/log/secure. Si en Debian quieres recuperar el archivo de texto, instala después rsyslog, en Debian y Ubuntu con apt-get install -y rsyslog, en la familia Red Hat con dnf install -y rsyslog.

El segundo comando del lado del servidor es todavía más importante, porque muestra la configuración que realmente está en vigor y, de paso, resuelve todos los archivos incluidos:

sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|strictmodes|permitrootlogin'

Si el comando, en lugar de una configuración, responde solo con Missing privilege separation directory: /run/sshd y no imprime ni una línea, es que falta simplemente un directorio de tiempo de ejecución. Eso ocurre en Debian 11, Debian 12, Ubuntu 22.04 y Ubuntu 24.04 justo después de instalar el paquete, mientras el servicio no se haya arrancado nunca, y también en contenedores. En funcionamiento normal, la unidad de systemd crea ella misma el directorio mediante RuntimeDirectory=sshd. Si aparece el mensaje, basta con anteponer un mkdir -p /run/sshd, y después sshd -T devuelve sin problemas permitrootlogin, pubkeyauthentication yes, strictmodes yes y authorizedkeysfile. Debian 13 con OpenSSH 10 y toda la familia Red Hat ya no tienen esa limitación. Ten en cuenta que el mensaje se pierde dentro de una tubería: sshd -T | grep ... muestra entonces solo una salida vacía y el verdadero código de retorno 255 desaparece en el grep.

Y si de verdad quieres ver qué piensa el servidor sin tocar el servicio en marcha: arranca una segunda instancia en modo de depuración en un puerto libre. Se cierra sola después de una conexión y no puede dejarte fuera.

/usr/sbin/sshd -ddd -p 2222

Desde tu equipo, lanza entonces ssh -p 2222 deploy@203.0.113.7, y en el terminal del servidor verás el rechazo en texto claro. Para eso, como es lógico, el puerto tiene que estar abierto en el firewall.

Causa 1: permisos y propietario, con diferencia el caso más frecuente

OpenSSH trae la opción StrictModes yes activada por defecto. El servidor se niega a leer una clave de un archivo en el que pueda escribir alguien más aparte del propio usuario. No es una manía, evita que otro usuario se limite a escribir su propia clave en tu authorized_keys.

El estado correcto está definido de forma estricta:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 750 ~
chown -R "$(id -un):$(id -gn)" ~/.ssh

Comprobarlo cabe en una sola línea:

stat -c "%a %U %G %n" ~ ~/.ssh ~/.ssh/authorized_keys

Se esperan 750 o 700 para el directorio personal, 700 para .ssh y 600 para authorized_keys, y en las tres líneas tu propio nombre de usuario. Lo decisivo es esto: el directorio personal no puede ser escribible para el grupo ni para los demás, así que 770 o 777 ya bastan para que todo falle.

Hay un número que no debes tomar por un error: en AlmaLinux, Rocky Linux y Oracle Linux, /root tiene los permisos 550, no 700 como en Debian y Ubuntu. stat -c lo muestra correctamente y es completamente normal. Para StrictModes solo cuenta que el grupo y los demás no tengan permiso de escritura, y eso es exactamente lo que cumple 550. Quien aquí añade un chmod 700 /root no ha reparado el acceso, solo ha tapado todavía más la causa.

En el log del servidor queda entonces muy claro:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh
Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys
error: Could not open authorized keys '/home/deploy/.ssh/authorized_keys': Permission denied

Dos detalles que otras guías suelen dejarse. Primero, el propietario: si creaste el archivo con sudo nano ~/.ssh/authorized_keys, pertenece a root y no al usuario, y el acceso falla pese a unos permisos 600 perfectos. Segundo, sshd comprueba toda la ruta hacia arriba. Si el directorio personal no está bajo /home, sino por ejemplo bajo /srv/clientes/deploy, también /srv y /srv/clientes tienen que pertenecer a root o al usuario y no pueden ser escribibles para el grupo ni para los demás.

Causa 2: el nombre de usuario equivocado

Un usuario que no existe genera exactamente el mismo mensaje que una clave incorrecta, porque el servidor no revela a propósito cuál de los dos casos se da. En el log la diferencia se ve enseguida:

Invalid user deply from 203.0.113.7 port 51234

El desencadenante más habitual es que la clave esté en /root/.ssh/authorized_keys mientras tú inicias sesión como usuario normal, o al revés. En las imágenes cloud ya preparadas, el acceso root suele estar bloqueado y en su lugar existe un usuario preconfigurado, según la distribución debian, ubuntu, almalinux o rocky. En cambio, con las imágenes estándar de un servidor root de KernelHost inicias sesión directamente como root.

Comprueba además si tu ~/.ssh/config te está colando otro usuario. El siguiente comando no establece ninguna conexión, solo muestra qué ajustes se aplican realmente a ese destino:

ssh -G deploy@203.0.113.7

De la salida te interesan user, hostname, port y la lista de entradas identityfile.

Causa 3: la clave ni siquiera se ofrece

Si en ssh -vvv no aparece ningún Offering public key con tu clave, el servidor nunca ha tenido su oportunidad. Para eso hay cuatro motivos típicos.

La clave tiene un nombre propio

De forma automática, OpenSSH solo prueba los nombres estándar id_ed25519, id_ecdsa e id_rsa. Una clave llamada id_produccion solo se usa si la indicas tú:

ssh -i ~/.ssh/id_produccion -o IdentitiesOnly=yes deploy@203.0.113.7

IdentitiesOnly=yes no es aquí un adorno. Sin esa opción, ssh ofrece además todas las claves del agente y, con demasiados intentos, el servidor corta con Too many authentication failures antes de que le llegue el turno a la clave correcta.

El agente no tiene la clave

ssh-add -l

Si el comando responde The agent has no identities. o Could not open a connection to your authentication agent., carga la clave con ssh-add ~/.ssh/id_ed25519.

Permisos de la clave privada

La clave privada tiene que estar en 600, si no el cliente se niega a usarla. En Windows chmod no surte efecto, allí se trabaja con ACL:

icacls %USERPROFILE%\.ssh\id_ed25519 /inheritance:r /grant:r "%USERNAME%":R

El archivo authorized_keys está estropeado

Una clave pública ocupa exactamente una línea. Al copiarla a través de editores, sistemas de tickets o ventanas de chat, es fácil que se cuele un salto de línea en mitad del bloque Base64, y entonces ya no encaja nada. Cuenta las líneas:

grep -c '^ssh-' ~/.ssh/authorized_keys
awk '{print NR": "NF" campos, tipo "$1}' ~/.ssh/authorized_keys

Cada línea tiene que empezar por ssh-ed25519, ssh-rsa o ecdsa-sha2- y constar de dos o tres campos. El número de líneas tiene que coincidir con el número de claves. Otro clásico es haber pegado por error la clave privada en lugar de la pública, algo que se reconoce por BEGIN OPENSSH PRIVATE KEY. Y una clave en formato PuTTY (.ppk) no funciona así, primero hay que exportarla a formato OpenSSH.

Si la clave privada y la pública se corresponden, lo aclara una comparación de huellas:

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh-keygen -lf ~/.ssh/authorized_keys

El mismo valor SHA256 tiene que aparecer en las dos salidas. Cómo queda todo esto montado desde cero y bien lo explicamos en nuestro artículo sobre cómo asegurar SSH y configurar el acceso por clave.

Causa 4: PubkeyAuthentication está desactivado

Menos frecuente, pero muy claro cuando pasa. No compruebes el archivo de configuración, comprueba el resultado:

sshd -T | grep -i pubkeyauthentication

Aquí acecha una trampa que cuesta muchas horas. Debian a partir de la versión 12 y Ubuntu a partir de 22.04 tienen arriba del todo, en /etc/ssh/sshd_config, la línea Include /etc/ssh/sshd_config.d/*.conf. En sshd rige lo siguiente: para cada palabra clave cuenta el valor encontrado en primer lugar. Como la inclusión está al principio, cualquier detalle de sshd_config.d gana frente al archivo principal, sin importar lo que ponga más abajo. Si tu cambio no surte efecto, mira ahí:

grep -rniE 'pubkeyauthentication|authorizedkeysfile|allowusers|allowgroups' /etc/ssh/

El segundo punto de esta categoría es AuthorizedKeysFile. Los valores estándar son .ssh/authorized_keys y .ssh/authorized_keys2. Algunos scripts de bastionado ponen la ruta en algo como /etc/ssh/authorized_keys/%u. A partir de ahí, tu archivo del directorio personal se ignora por completo, sin ningún mensaje de error. Eso también lo muestra sshd -T.

Causa 5: AllowUsers, AllowGroups y Match entran en juego

Estas directivas dejan fuera a grupos enteros de usuarios, y lo hacen antes de que la clave se llegue a comprobar. El texto exacto en el log:

User root from 203.0.113.7 not allowed because not listed in AllowUsers
User deploy from 203.0.113.7 not allowed because none of user's groups are listed in AllowGroups
User root from 203.0.113.7 not allowed because "PermitRootLogin no"

Recuerda el orden de prioridad: DenyUsers gana a AllowUsers, y en cuanto AllowUsers está definido, todos los usuarios no mencionados quedan fuera. Con AllowGroups, la pertenencia al grupo tiene que ser correcta, algo que compruebas con id deploy.

En PermitRootLogin la distinción es importante: prohibit-password permite el acceso root con clave. Solo no bloquea root por completo. Eso sí, en la salida de sshd -T no esperes la palabra prohibit-password: ahí figura el nombre antiguo y equivalente without-password. Y el valor predeterminado no es igual en todas partes, algo que genera confusión con frecuencia al comparar dos servidores:

En AlmaLinux, por tanto, root también puede entrar con contraseña; en los demás sistemas mencionados, no. Quien mueve un servicio de AlmaLinux a Debian y hasta entonces iniciaba sesión como root con contraseña, acaba justo en Permission denied (publickey).

Si la regla está dentro de un bloque Match, ayuda la opción que evalúa la configuración para un caso concreto:

sshd -T -C user=deploy,host=client.example.com,addr=203.0.113.7 | grep -Ei 'pubkeyauth|allowusers|permitrootlogin'

Es la forma más fiable de ver qué se aplica exactamente a ese usuario desde exactamente esa dirección IP.

Causa 6: SELinux en AlmaLinux, Rocky y RHEL

En la familia Red Hat, SELinux funciona por defecto en modo Enforcing; en Debian y Ubuntu no juega ningún papel. El proceso sshd solo puede leer authorized_keys si el archivo lleva el contexto ssh_home_t. Ese es el caso cuando se ha creado con normalidad dentro del directorio personal. No lo es cuando lo has traído de /tmp con mv o has creado el directorio personal a mano, porque mv se lleva consigo el contexto antiguo.

getenforce
ls -Z ~/.ssh

Lo correcto es una entrada que termine en ssh_home_t. Si ahí pone user_tmp_t o user_home_t, ya tienes la causa. La reparación:

restorecon -R -v ~/.ssh

Este paso vale exclusivamente para la familia Red Hat. En Debian y Ubuntu no hay una instalación estándar de SELinux, allí el shell responde restorecon: command not found, y eso no es un error, simplemente no aplica. Pero también en AlmaLinux y Rocky Linux falta el comando en una instalación ligera, porque el paquete correspondiente no está puesto. En ese caso, instálalo antes:

dnf install -y policycoreutils

Las pruebas están en el log de auditoría, donde el rechazo consta en texto claro:

ausearch -m avc -ts recent

Si los directorios personales están en una ubicación poco habitual, restorecon por sí solo no basta, porque SELinux no reconoce esa ruta como directorio personal. Entonces declaras la equivalencia una sola vez y después restauras:

semanage fcontext -a -e /home /srv/clientes
restorecon -R -v /srv/clientes

semanage está en el paquete policycoreutils-python-utils. No desactives SELinux para que el acceso funcione, eso resuelve un problema de dos comandos a costa de una pérdida de seguridad en toda la máquina.

Causa 7: servidor antiguo, tipo de clave equivocado

Desde OpenSSH 8.8, el cliente rechaza las firmas RSA con SHA-1. Ubuntu 22.04 ya está afectado, y Debian 13 trae ya OpenSSH 10. Si desde un sistema tan actual quieres llegar a un servidor muy antiguo que solo maneja el viejo ssh-rsa, en la salida de depuración verás:

debug1: send_pubkey_test: no mutual signature algorithm

No es un problema de permisos, tu clave está perfectamente bien. Para un acceso puntual sirve:

ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa deploy@203.0.113.7

De forma permanente, eso va en ~/.ssh/config bajo una entrada Host, para que afecte solo a ese servidor. En clientes muy antiguos, la opción todavía se llama PubkeyAcceptedKeyTypes. La solución de verdad es actualizar el servidor antiguo, porque a partir de OpenSSH 7.2 él también maneja las variantes SHA-2, y tu clave RSA actual sigue funcionando sin cambios. Solo cambia el procedimiento de firma.

El caso contrario también existe. Una clave ed25519 necesita como mínimo OpenSSH 6.5 en ambos lados, y los tokens de hardware del tipo ed25519-sk como mínimo la 8.2. Y DSA es historia: desde OpenSSH 10.0, ssh-dss está eliminado por completo, así que esas claves antiguas ya no funcionan frente a Debian 13. Qué tipos conoce tu cliente lo muestra:

ssh -Q key

Si en un AlmaLinux, Rocky Linux o RHEL recién instalado falta ssh por completo, se debe a una trampa en los nombres de los paquetes: dnf install openssh-server solo trae el servicio, no las herramientas de cliente. Sin ellas faltan ssh, ssh-add y, con ellos, también ssh -Q y ssh -G. Se instala con s de plural, a diferencia del paquete de Debian openssh-client:

dnf install -y openssh-clients

En AlmaLinux, Rocky y RHEL 9 se suma un segundo nivel. Allí, unas políticas criptográficas de todo el sistema también deciden qué está permitido, con independencia de la configuración de sshd:

update-crypto-policies --show

Esta herramienta también es exclusiva de Red Hat, en Debian y Ubuntu no existe. E incluso en Oracle Linux 9 falta en la instalación mínima, allí la aporta dnf install -y crypto-policies-scripts, y después sale DEFAULT como cabía esperar. Si ahí pone DEFAULT, las firmas SHA-1 ya están bloqueadas en todo el sistema. update-crypto-policies --set LEGACY lo desbloquea, pero debilita la máquina entera y, como mucho, debería ser una solución de transición para una migración.

Si te has quedado fuera

El momento peligroso no es el fallo en sí, sino la reparación de sshd_config. Tres reglas que hacen que quedarse fuera sea prácticamente imposible:

1. Deja una segunda sesión abierta. Un reinicio de sshd no corta las conexiones existentes. Mientras siga abierto un terminal, puedes deshacer cualquier cambio.
2. Comprueba la sintaxis antes de cada reinicio. sshd -t indica el número de línea cuando hay errores y calla cuando todo está bien. Si no, una errata en la configuración impide que el servicio arranque, y entonces ya no entra nadie. Si en su lugar aparece Missing privilege separation directory: /run/sshd, tu configuración está en orden y solo falta el directorio de tiempo de ejecución, como se ha visto arriba.
3. Haz la prueba desde la segunda sesión, antes de cerrar la primera.

En el reinicio los sistemas se diferencian. En Debian y Ubuntu la unidad se llama ssh, en la familia Red Hat sshd. Desde Ubuntu 22.10 y en Debian 13, SSH se arranca además mediante activación por socket: la configuración de sshd_config sigue siendo válida, pero un valor Port modificado no surte efecto hasta que se reinicia también ssh.socket.

sshd -t
systemctl restart ssh          # Debian, Ubuntu
systemctl restart ssh.socket   # adicionalmente, si se ha cambiado el puerto
systemctl restart sshd         # AlmaLinux, Rocky, RHEL

Si aun así ocurre, necesitas un camino que rodee SSH. En un servidor root de KernelHost abres la consola VNC en el área de cliente y te identificas ahí con la contraseña de root, sin ningún servicio de red de por medio. Si eso no te lleva a ninguna parte, por ejemplo porque sshd ya no arranca, te ayuda el sistema de rescate: arrancas en un entorno de emergencia, montas el sistema de archivos y corriges authorized_keys y los permisos directamente en el disco. Acuérdate de comprobar los propietarios después de montar, porque en el sistema de rescate eres root y, si no, creas los archivos con el propietario equivocado.

Cómo saber que de verdad funciona

Que un inicio de sesión salga bien no significa todavía que haya ido por la clave. Mientras la autenticación por contraseña esté activa, el servidor puede dejarte caer en silencio a ese método. La prueba honesta excluye cualquier otra vía:

ssh -o BatchMode=yes -o PreferredAuthentications=publickey deploy@203.0.113.7 'id -un; hostname'

BatchMode=yes suprime cualquier pregunta interactiva. Si vuelven tu nombre de usuario y el nombre de host y echo $? devuelve después un 0, ha trabajado únicamente la clave.

La segunda prueba está en el log del servidor y menciona incluso la huella de la clave utilizada:

Accepted publickey for deploy from 203.0.113.7 port 51234 ssh2: ED25519 SHA256:8Qk...

Compara ese valor SHA256 con la salida de ssh-keygen -lf ~/.ssh/id_ed25519.pub. Si los dos coinciden, no solo sabes que el acceso funciona, sino también qué clave se usó. Eso es relevante cuando hay varias claves en juego y quieres retirar una de ellas.

El orden en el que trabajar

Si no tienes tiempo para la teoría, repasa esta lista de arriba abajo. Está ordenada por frecuencia, no por elegancia.

1. Lanzar ssh -vvv y comprobar si aparece Offering public key. Eso divide el problema entre cliente y servidor.
2. Comprobar permisos: 700 en ~/.ssh, 600 en authorized_keys, directorio personal no escribible por el grupo, todo en propiedad del usuario.
3. Comprobar el nombre de usuario, en caso de duda consultar ssh -G y buscar Invalid user en el log.
4. Comparar las huellas de la clave privada y de authorized_keys, controlar el número de líneas del archivo.
5. Analizar sshd -T: pubkeyauthentication, authorizedkeysfile, strictmodes, permitrootlogin.
6. Revisar AllowUsers, AllowGroups, DenyUsers y los bloques Match, incluido el directorio sshd_config.d.
7. En la familia Red Hat, ls -Z ~/.ssh y, si hace falta, restorecon -R -v ~/.ssh.
8. Solo con contrapartes muy antiguas: ampliar el algoritmo de firma con PubkeyAcceptedAlgorithms=+ssh-rsa.

A más tardar aquí, la causa está encontrada. Si después quieres montar el acceso de nuevo y de forma limpia, la introducción a la conexión por SSH y la lista de comprobación para un servidor root nuevo son los puntos de continuación adecuados.