Watch at EaseHistorias. Respuestas. Perspectiva.

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.

Ilustración original: separa destino SSH efectivo, huella ofrecida, autorización de cuenta y política del servidor.
Ilustración original: conserve cuatro columnas de evidencia y cambie solo el límite probado. Watch at Ease

«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.

Ilustración original: bifurca según si se ofreció realmente la huella SSH prevista.
Ilustración original: no ofrecida es selección del cliente; ofrecida y rechazada pasa a autorización y política. Watch at Ease