SSH renvoyant soudainement un format non valide


23

Il y a quelque temps, j'ai installé un serveur sur AWS et utilisé leur clé SSH générée. J'ai enregistré la clé dans Lastpass, et je l'ai récupérée avec succès avant, et je l'ai fait fonctionner. Cependant, après avoir essayé à nouveau aujourd'hui, je ne peux pas le faire fonctionner.

-rw------- 1 itsgreg users 1674 Jun 6 12:51 key_name

J'ai essayé ssh -i key_name, ssh-keygen -f key_namemais rien ne fonctionne, je reçois toujours ce message d'erreur:

Load key "key_name": invalid format

Y a-t-il un moyen de réparer ceci?

Réponses:


13

Vérifiez le contenu de key_name, si l'agent dit invalid format, alors il y a quelque chose qui ne va pas avec la clé - comme .. êtes-vous sûr que c'est la bonne clé? Même si ce n'est pas la clé privée dont vous avez besoin, l'agent ssh ne reviendra pas invalid formatsi la clé fonctionne, vous ne pourrez tout simplement pas vous connecter. Vous pourriez y avoir placé votre clé publique, pour une raison quelconque. Vérifie ça!


5
Certainement vérifié. Commence par ----BEGIN RSA PRIVATE KEY-----et se termine par -----END RSA PRIVATE KEY-----. De plus, cela fonctionnait.
Gregor Menih

2
Il est très improbable, mais toujours possible, que le fichier soit corrompu. Créez-en un nouveau et remplissez à nouveau le contenu depuis lastpass.
13dimitar

2
Wow, ça a vraiment aidé! Après avoir généré la nouvelle clé, j'ai remarqué que la nouvelle clé avait 64 caractères par ligne alors que mon ancienne clé en avait 76. J'ai reformaté mon ancienne clé pour avoir seulement 64 caractères par ligne, puis elle a commencé à fonctionner! Il me manquait également un tiret de la première ligne.
Gregor Menih

2
"Il me manquait également un tiret de la première ligne." Idem. Merci @ItsGreg pour cela. Le premier caractère me manque si souvent lors de la sélection et de la copie entre les terminaux!
Starfry

15

Ce que j'ai fait pour résoudre ce problème, c'est que j'utilise pour convertir le fichier PPK en utilisant PuttyGen.

urkey.PPKChargez d' abord le , puis dans le menu de conversion, cliquez sur exporter au format de fichier Openssh. Il créera un fichier newkey.

maintenant, ssh -i "newkey" user@127.0.0.1

Terminé. J'espère que cela aide.


4

Je demandais à openssh d'utiliser un fichier d'identité particulier en le spécifiant dans le fichier .ssh / config.

La configuration de travail d'origine avait

IdentityFile = <path to public key file> 

Cela a cessé de fonctionner sans aucun changement. En réfléchissant un peu, j'ai remplacé le "chemin d'accès au fichier de clé publique" ci-dessus par "le chemin d'accès au fichier de clé privée". Ça a marché. Le raisonnement est que les fichiers de clés publiques et privées ont de grands nombres liés à peudoprime selon l'algorithme RSA. Si vous remplacez le fichier de clé privée par un fichier de clé publique, ces numéros cryptographiques ne seront pas extraits correctement du bloc base64 enregistré dans les fichiers de clé. Il semble que certaines versions de ssh peuvent comprendre l'extension .pub et l'utiliser pour identifier le fichier de clé privée correct - et d'autres versions ne le font pas. C'est une autre façon dont cette erreur peut se produire. J'espère que cela aide quelqu'un.


Dans mon cas, j'avais un configfichier d' installation avec path_to_public_keyet tout fonctionnait. Cependant, lorsque le mac a fait un redémarrage difficile et quelques jours plus tard, j'ai essayé de le faire git push, j'ai commencé à obtenir l'erreur indiquée ci-dessus. Mais quand je l'ai changé, les path_to_private_keychoses fonctionnent ... Hmmm. Je ne sais pas pourquoi ..
Lukik

3

J'ai eu le même problème, et il s'avère que j'avais des séparateurs de ligne de style Windows (CRLF) dans le fichier pour une raison quelconque.

De plus, le fichier doit se terminer par un seul LF.

Réparer ces choses rendait les choses encore dandy.


Il est choquant que ce LF final soit si nécessaire, mais c'était en partie le problème, l'autre partie étant que j'ai créé le fichier dans Windows et que cela lui donne des sauts de ligne CRLF. Pour la référence des autres, dos2unixest la commande pour convertir des sauts de ligne CRLF (style Windows) en LF (style Linux).
Hashim

1

Vous devez convertir votre clé .ppk en clé OpenSSH

Voici comment procéder :

  1. Téléchargez PuttyGen et générez votre paire de clés (si vous n'avez pas de paire de clés prête). Enregistrez la clé privée dans votre dossier (.ppk)
  2. Si vous disposez déjà de la clé privée, chargez le fichier de clé privée (.ppk) en appuyant sur le bouton "Charger". Sinon, ignorez cette étape
  3. Dans le menu "Conversions", choisissez Exporter la clé OpenSSH puis enregistrez-la dans votre dossier
  4. Vous êtes maintenant prêt à utiliser la clé pour vous connecter à votre serveur sans taper le mot de passe (je suppose que vous avez déjà mis la clé publique sous /root/.ssh/authorized_keys, chmod 600 /root/.ssh/authorized_keys, et le démon SSH redémarré)

1

Je suis juste tombé sur cela aujourd'hui alors que j'écrivais des utilitaires de marquage git pour mon pipeline CI.

Voici la différence entre mes deux clés:

$ diff ~/.ssh/gitlab ~/.ssh/git_ssh_key
27c27
< -----END OPENSSH PRIVATE KEY-----
---
> -----END OPENSSH PRIVATE KEY-----
\ No newline at end of file

J'ai changé mon code comme ceci:

     with open(ssh_key_file, 'w') as skf:
-        skf.write(ssh_key)
+        skf.write(ssh_key + '\n')

Et maintenant ma clé ssh fonctionne.

TL; DR - Je suppose que vous devez avoir une nouvelle ligne à la fin de votre clé privée.


1

Dans mon cas, il s'est avéré que j'avais des retours à la ligne entre les "en-têtes" de début / fin et les données clés:

-----BEGIN RSA PRIVATE KEY-----

- Key data here -

-----END RSA PRIVATE KEY-----

Suppression des nouvelles lignes supplémentaires, il est donc devenu

-----BEGIN RSA PRIVATE KEY-----
- Key data here -
-----END RSA PRIVATE KEY-----

résolu mon problème.


0

Utilisez votre clé privée au lieu de la clé publique.


même solution que ma réponse - où une explication est également ajoutée
vpathak

0

J'ai eu ce problème car j'avais une clé dans ~ / .ssh qui était en fait un format invalide et j'avais beaucoup de clés, ce qui signifiait que SSH les essayait toutes, même si j'avais spécifié mon fichier d'identité dans la commande. Il se trouve que cela échoue car il ne peut essayer que 5 clés, je pense, puis m'a laissé cette erreur, qui était légitime, juste pour le mauvais fichier d'identité. La solution était de simplement utiliser IdentitiesOnly yesdans mon ~ / .ssh / config.


0

J'ai eu cette erreur car il y avait une ligne vierge au début du fichier clé. Facile à manquer si vous catle sortez.


0

Il s'agit également de l'erreur que ssh (au moins certaines versions) émet si vous avez une phrase secrète sur votre clé privée et entrez une phrase secrète incorrecte lorsque vous essayez de vous connecter.

(En particulier, cela m'est arrivé avec: OpenSSH_7.6p1, LibreSSL 2.6.2, qui est le SSH intégré pour Mac OS X 10.13.6.)

Vérifiez donc que vous utilisez la bonne phrase de passe et que VERR MAJ est désactivé.


-2

Assurez-vous de renommer votre clé PRIVÉE et de supprimer l'extension de fichier à l'origine du problème.

Mesures que j'ai prises

Créez votre clé publique:

Assurez-vous que vous êtes dans le même répertoire que vous avez la clé privée

Comment créer la clé publique:

ssh-keygen -y -f Private-Key.pem > Public-key.pub

assurez-vous que la clé PUBLIC a une extension de fichier .pub

après cela, fournissez les autorisations appropriées pour des raisons de sécurité:

chmod 600 Private-Key.pem
chmod 400 Public-key.pub

ALORS la partie la plus importante et la raison pour laquelle vous avez obtenu l'erreur "format invalide"

Assurez-vous de renommer votre clé PRIVÉE et de supprimer l'extension de fichier:

Supprimez le .pem de votre clé privée.

mv Private-Key.pem Private-Key

ou si sur un ordinateur Windows renommer la clé privée, même nom supprimez simplement le .pem

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.