Tecnología · GUÍA PRÁCTICA
¿SSH dice «Permission denied (publickey)»? Demuestre la huella ofrecida antes de copiar otra clave
Imprima el destino efectivo, capture la huella realmente ofrecida, relaciónela con la cuenta y revise el rechazo antes de cambiar permisos o política.

«Permission denied (publickey)» significa que la conexión llegó a la autenticación de usuario, pero el servidor no aceptó una ruta de clave pública utilizable para la cuenta solicitada. No identifica la capa que falló.
Cree un registro de cuatro columnas: destino efectivo, huellas ofrecidas, autorización de cuenta y evidencia del rechazo del servidor. Corrija solo la primera unión rota.
Fije el destino y el llamador exactos
Conserve comando, alias, usuario remoto, puerto, salto y contexto. Ejecute ssh -G con ese destino y registre la configuración efectiva, también dentro del IDE o servicio cuando sea posible.
No deduzca la cuenta remota del usuario local o DNS. La autorización pertenece a una cuenta remota concreta.
Registre solo claves realmente ofrecidas
En la sección de autenticación de ssh -vvv anote origen y huella de cada «Offering public key». Archivo ausente y clave ofrecida pero rechazada son ramas distintas.
Si no aparece la huella prevista, revise IdentityFile, socket del agente y HOME; pruebe -i con IdentitiesOnly=yes y confirme la oferta.
Una la huella con la cuenta prevista
Obtenga SHA256 de la clave pública o lista aprobada del agente sin exponer material privado. Compare con la clave registrada en la cuenta remota o del proveedor.
No vuelva a copiar una clave hasta conocer esta unión; podría ampliar autorización sin cambiar el contexto que falla.
Pase al servidor solo tras un rechazo ofrecido
Si la huella correcta se ofreció y fue rechazada, revise en el servidor autorizado logs y fuente real: cuenta, AuthorizedKeysFile, directorio gestionado, propietario, modos, certificados, Match y algoritmos.
Evite chmod recursivo o rebajar autenticación. Corrija solo el requisito probado y repita desde el llamador original.
Cierre con evidencia antes y después
Repita ssh -G y ssh -vvv desde el contexto que fallaba; confirme destino, cuenta, huella y éxito sin degradación.
Guarde el registro saneado con hora y llamador para comparar futuros cambios de IDE, agente, alias o cuenta.
