Esta duda se puede solucionar de diversas maneras, pero en este caso te dejamos la solución más completa para nosotros.
Solución:
Tradicionalmente, OpenSSH usaba el mismo privado key El formato es idéntico al antiguo formato PEM utilizado por OpenSSL. (Porque usa OpenSSL para analizar el keytambién aceptará el formato PKCS#8 más reciente).
Entonces el problema puede ser uno de:
-
Su versión de OpenSSL se niega a cargar esto key formato. ¿Quizás ha habilitado accidentalmente el modo FIPS y rechaza cualquier algoritmo excepto aquellos que forman parte de su validación FIPS original?
Intenta cargar el key en el
opensslherramienta de línea de comandos (que, sí, también podría estar vinculada a una libcryptoy usted debe consultar con ldd):openssl rsa -noout -text < id_rsa openssl pkey -noout -text < id_rsaIntente convertirlo al formato PKCS#8:
umask 077 openssl pkey < id_rsa > id_rsa.pkcs8 ssh-add id_rsa.pkcs8 -
Su OpenSSH se ha creado sin compatibilidad con OpenSSL. A pesar de
ssh -Vdice que se habilitó el soporte, que no significa automáticamente lassh-addel binario es el mismo: puede provenir de una instalación parcial diferente.Usar
type -a sshytype -a ssh-addpara comparar las ubicaciones de instalación.Una vez que sepa la ruta, utilice
ldd /usr/bin/ssh-addpara verificar que está vinculado alibcrypto.so(la biblioteca criptográfica OpenSSL).
Si nada funciona, intente convertir su key al nuevo formato propietario de OpenSSH usando... PuTTY. Instala el putty paquete para Fedora, y use:
puttygen id_rsa -o id_rsa.newformat -O private-openssh-new
ssh-add id_rsa.newformat
También peculiar: GNOME de alguna manera se las arregla para agregar el key al iniciar sesión con caballito de mar.
Las versiones anteriores de GNOME Keyring tienen una copia interna del código del agente SSH y son independientes del sistema OpenSSH. Entonces ellos aceptarán keys que su OpenSSH no lo hará. (Pero por otro lado, esto significa un retraso severo en términos de soporte de funciones (como Ed25519 keys), y el último llavero de GNOME solo usa el agente ssh del sistema en su lugar).
Recibía el mismo mensaje de error al pasar en privado key a través de una variable de canalización de CI en Gitlab.
El error se produjo por no tener un carácter de nueva línea al final de la variable y se solucionó al agregarlo manualmente.
En mi caso, el problema fue causado por caracteres de final de línea incorrectos en el archivo id_rsa. Después de copiar el contenido del archivo, el editor de texto de Windows quiso ayudarme y convirtió los EOL a CR LF.
valoraciones y comentarios
Ten en cuenta difundir esta división si te valió la pena.