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 n'arrive 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_name
, mais rien ne fonctionne, je reçois toujours ce message d'erreur:
Load key "key_name": invalid format
Est-ce qu'il y a un moyen de réparer ceci?
Vérifiez le contenu de key_name
, si l'agent dit invalid format
, alors il y a un problème 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 retournera pas invalid format
si la clé fonctionne, vous ne pourrez tout simplement pas vous connecter. Vous avez peut-être placé votre clé publique là-dedans, pour une raison quelconque. Vérifie ça!
Ce que j'ai fait pour résoudre ce problème, c'est que j'utilise pour convertir le fichier PPK en utilisant PuttyGen
.
Chargez d'abord le urkey.PPK
, puis dans le menu de conversion, cliquez sur exporter au format de fichier Openssh. Il créera un fichier de nouvelle clé.
maintenant, ssh -i "newkey" [email protected]
Terminé. J'espère que cela aide.
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.
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.
Vous devez convertir votre clé .ppk en clé OpenSSH
Voici comment vous le faites:
Dans mon cas, il s'est avéré que j'avais des nouvelles lignes 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.
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.
Utilisez votre clé privée au lieu de la clé publique.
Mon problème était dû à l'encodage. En regardant dans VSCode l'encodage du fichier (que j'avais créé en utilisant Out-File
dans PowerShell) était UTF-16LE
. Lorsque je suis passé à UTF-8
, la clé était valide.
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 consistait à utiliser simplement IdentitiesOnly yes
dans ma ~/.ssh/config.
J'ai eu cette erreur car il y avait une ligne vierge au début du fichier clé. Facile à manquer si vous le faites cat
.
C'est également 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é.