Load key "/path/to/key": invalid format

La ruta se rellena en cada invocación. El texto depende de la biblioteca criptográfica con la que se compiló OpenSSH: con OpenSSL 1.1 o LibreSSL (macOS), todos los fallos que se describen a continuación imprimen «invalid format»; las compilaciones con OpenSSL 3 (Ubuntu 22.04 y posteriores, Debian 12 y posteriores) imprimen «error in libcrypto» en la mayoría de ellos y mantienen «invalid format» para las claves en formato PEM dañadas. Un carácter cambiado dentro del cuerpo produce «unknown or unsupported key type» en todas las compilaciones.

OpenSSH — ssh, ssh-keygen, ssh-add

Qué significa

OpenSSH intentó cargar un archivo de clave privada y no pudo analizarlo en ninguno de los formatos que conoce (OPENSSH PRIVATE KEY, PKCS#8, PEM heredado). El archivo está dañado o truncado, tiene un formato ajeno como el .ppk de PuTTY o ni siquiera es una clave privada: es un fallo de formato del archivo, anterior a cualquier frase de contraseña o interacción con el servidor.

Por qué ocurre

• La clave se dañó al copiarla y pegarla

  frecuente

  Las claves que pasan por un chat, el correo electrónico o terminales pierden los saltos de línea finales, ganan líneas partidas o caracteres tipográficos, o pierden los guiones finales. El cuerpo base64 de un bloque OPENSSH PRIVATE KEY depende de la longitud exacta; un solo carácter perdido invalida el archivo. (La falta del salto de línea final, por sí sola, es una causa clásica.)

• Archivo .ppk de PuTTY usado con OpenSSH

  frecuente

  El formato de clave de PuTTY («PuTTY-User-Key-File-2: ...») no es el de OpenSSH. Si apuntas ssh -i a un .ppk, falla exactamente aquí; hay que convertir la clave una vez.

• Clave pública en lugar de la clave privada

  frecuente

  ssh -i id_ecdsa.pub (el archivo .pub) o una línea de authorized_keys guardada como archivo de identidad: el cargador de claves privadas encuentra contenido de clave pública y devuelve «invalid format».

• Archivo truncado o sincronizado a medias

  ocasional

  Un archivo de clave cortado a mitad del cuerpo por una sincronización en la nube o una copia scp interrumpida se analiza como basura. Reproducido: truncar un archivo de clave válido produce exactamente «invalid format» en OpenSSH 8.4 y en macOS.

Cómo solucionarlo

1. 1.

   Inspeccionar primero los delimitadores

   La primera y la última línea, junto con una prueba de validez (-y imprime la clave pública si, y solo si, la clave privada se puede analizar), identifican el tipo de fallo en segundos.

   head -1 ~/.ssh/id_ecdsa      # -----BEGIN OPENSSH PRIVATE KEY-----
   tail -c 50 ~/.ssh/id_ecdsa | xxd | tail -1   # must end with 0a (newline)
   ssh-keygen -y -f ~/.ssh/id_ecdsa             # parses? prints the public key

2. 2.

   Convertir las claves de PuTTY al formato OpenSSH

   Una conversión única con puttygen; después, la clave funciona con ssh, ssh-add y ssh-agent.

   puttygen key.ppk -O private-openssh -o ~/.ssh/id_converted
   chmod 600 ~/.ssh/id_converted

3. 3.

   Transferir las claves sin pérdidas

   Mueve los archivos de clave con scp/rsync en lugar del portapapeles, mantén los permisos en 600 y, si la clave privada no se puede recuperar, genera un par nuevo: las versiones modernas de OpenSSH prefieren Ed25519.

   scp -p old-host:~/.ssh/id_ecdsa ~/.ssh/
   # or start clean:
   ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

← Explorar toda la base de datos de errores de firma