■ space · el cable, repetido · fig 1

■ la respuesta primero

Permission denied (publickey) = todas las claves que ofreció el cliente fueron rechazadas — un veredicto de negociación, no una errata de contraseña.

Diagnóstico: ssh -vvv muestra qué claves se ofrecieron; journalctl -u ssh muestra por qué las rechazaron.

Luego es una de cuatro causas: usuario equivocado, clave fuera de authorized_keys, permisos demasiado abiertos, o ssh-rsa rechazado por OpenSSH 8.8+. ssh-copy-id previene la mayoría de las reincidencias.

4causas detrás de un veredicto

8.8primer OpenSSH en rechazar ssh-rsa

02:10la oferta que murió

01EL CABLE

el cliente propone · el servidor rechaza · tres líneas deciden en qué lado vive tu problema

FIG 1 · LA CINTA TRANSPORTADORA DE LLAVESclaves 1–6 — o los botones

repite la jugada desde la terminal

$ ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
debug1: Offering public key: /home/deploy/.ssh/id_rsa RSA SHA256:9T4xQmV…

02:10:03 — RECHAZADO. EL DEPLOY MURIÓ POR SSH-RSA02:14:41 — el mismo cliente, aceptado en ed25519

OFERTA id_rsa → RECHAZADA · OFERTA id_ed25519 → ACEPTADA · REGISTRO 1R · 1A

la cinta es la lista de ofertas — cada sello que toma el anillo, ssh -vvv se imprime como una línea

02EL TESTIGO

el anillo guarda la cuenta — el servidor guardó la suya primero: journalctl ya registró cada veredicto

staging · el propio log de sshd

Oct 18 02:10:03 staging sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:9T4xQmV…
Oct 18 02:14:41 staging sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:KP7wLn…

dos líneas, un arco: la oferta RSA rechazada a las 02:10 — la muerte del deploy — luego el mismo cliente, cuatro minutos después, aceptado en ed25519

por qué fue rechazada — en Ubuntu, sshd registra veredictos por cada oferta

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"

verificación: journalctl -u ssh -n 50 | grep Accepted → una línea con TU huella y tu usuario

03LA TABLA DE CAUSAS

el log nombra el veredicto, nunca la causa — seis formas producen un rechazo

causa	seña reveladora	arreglo
La clave correcta existe, llega la equivocada	`-vvv` ofrece una identidad que no reconoces	`ssh-add -l` para listar, `ssh-add -d` para soltar la manida
`-i mykey` ignorado	Un IdentityFile de la config pisa el orden de ofertas	Arregla o quita el bloque de `~/.ssh/config`
Clave no instalada	El log del servidor muestra `Failed publickey` en cada oferta — authorized_keys: vacío, 0 claves	`ssh-copy-id user@host`
Usuario equivocado	La clave funciona para `root@host`, falla para `deploy@host`	La clave debe estar en el `~/.ssh/authorized_keys`
Permisos demasiado abiertos	`WARNING: UNPROTECTED PRIVATE KEY FILE` — la clave se salta, nunca se ofrece	`chmod 700 ~/.ssh; chmod 600 ~/.ssh/*`
Clave ssh-rsa heredada	El servidor corre OpenSSH 8.8+; la clave RSA vieja nunca se acepta	Regenérala como ed25519, o actualiza la clave

cada fila se repite en el cable — pulsa su clave en la cinta y mira a la negociación elegir esa causa

REGLA 01Tres líneas deciden el lado. Ofrecida · aún aceptada · rechazada — léelas en orden y el cable te dice dónde estar.

REGLA 02ssh-copy-id, nunca pegar a mano. Líneas parciales y permisos flojos: así nace la reincidencia.

REGLA 03BatchMode es la prueba. ssh -o BatchMode=yes … 'echo ok' — sin prompt, sin esperanza, solo ok.

04LA COMPUERTA DE PERMISOS

cada causa de la tabla llegó hasta el servidor — esta muere en el lado cliente del cable

~/.ssh— el directorio, ls -ld700 → drwx------ · 755 es demasiado abierto

~/.ssh/id_ed25519— la clave privada, ls -l600 → -rw------- · 644 y 664 son demasiado abiertos

■ el cliente te rechaza tu propia clave por ti WARNING: UNPROTECTED PRIVATE KEY FILE. una clave legible por el grupo o por todos se descarta en silencio de la oferta — nada llega al servidor; el log de -vvv no muestra ni una línea offering

el arreglo — dos chmod, en orden

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*

verificación: ls -ld ~/.ssh → drwx------ · ls -l ~/.ssh/id_ed25519 → -rw-------

05LA LENGUA JUBILADA

un rechazo lleva fecha — 8.8, publicado el 2021-10-01, dejó de hablar ssh-rsa

«el esquema de firmas ssh-rsa está ... deshabilitado por defecto» — notas de la versión OpenSSH 8.8, 2021-10-01.

una clave RSA generada en 2018 no está rota — su formato de firma simplemente ya no se habla

la respuesta durable—ssh-keygen -t ed25519 — una clave nueva en la lengua que todos los servidores aún hablan

la misma clave, mejorada—rsa-sha2-256 no necesita regenerarse — la firma se mejora en su sitio

la instalación—ssh-copy-id añade la clave y deja permisos sanos — existe porque pegar a mano falla con líneas parciales

fábrica la clave, instálala

ssh-keygen -t ed25519
ssh-copy-id deploy@staging

la prueba — sin prompt, sin esperanza

$ ssh -o BatchMode=yes deploy@staging 'echo ok'
ok

verificación: ssh -o BatchMode=yes deploy@staging 'echo ok' → ok, sin prompt

LA CLÁUSULA DEL CIERRE ¿Miedo de quedarte fuera mientras arreglas? Las consolas cloud te dan una consola serie que no depende de sshd — todos los proveedores de VPS tienen una. si la autenticación por contraseña ya está deshabilitada y tu arreglo toca authorized_keys, deja esa consola abierta antes de reiniciar cualquier cosa

■ sello honesto Probado en: OpenSSH 8.8 → 9.x · Ubuntu · claves ed25519 + RSA · ssh-agent. Primera publicación 2026-09-18. La mecánica ofrece-y-rechaza, el rechazo UNPROTECTED PRIVATE KEY y el valor por defecto de ssh-rsa en 8.8 son comportamiento documentado de OpenSSH; las líneas de -vvv y journalctl de arriba son las formas exactas que esas herramientas imprimen, tecleadas desde deploys que murieron a las 02:10 y volvieron.

fin del cable · nada fetchado · todo local