J'ai deux fichiers, id_rsa y id_rsa.pub . Quelle commande peut être utilisée pour valider s'ils sont un valide paire ?
Je préférerais que le ssh-keygen -y -e -f <private key> au lieu de la réponse acceptée, à savoir Comment tester une paire de clés DSA publique/privée ? sur Stack Overflow.
ssh-keygen -y -e -f <private key> prend une clé privée et imprime la clé publique correspondante qui peut être directement comparée à vos clés publiques disponibles. (Indice : méfiez-vous des commentaires ou des options de clé).
(Comment diable fait-il cela ? Je ne peux qu'espérer que la clé publique est encodée directement ou indirectement dans la clé privée...)
J'en ai eu besoin moi-même et j'ai utilisé le code Bash suivant. Cela ne devrait rien donner si les clés sont identiques. Appliquer un petit -q au diff dans scripts et diff ne fait que définir le code de retour de manière appropriée.
PRIVKEY=id_rsa
TESTKEY=id_rsa.pub
diff <( ssh-keygen -y -e -f "$PRIVKEY" ) <( ssh-keygen -y -e -f "$TESTKEY" )
"La clé privée est générée de façon aléatoire, de sorte que nous avons tous une clé unique. Si vous appliquez l'algorithme RSA à sens unique répétable sur cette clé privée, vous obtiendrez la clé publique unique. Il n'y a pas d'algorithme que vous pouvez exécuter sur la clé publique pour obtenir une clé privée unique.
@Sirch : Je pensais que la décision de savoir quelle clé est privée et quelle clé est publique était purement aléatoire puisque les deux clés sont égales. Ce qu'une clé crypte ne peut être décrypté qu'avec l'autre. Et si une clé pouvait être obtenue de l'autre, tout cela ne fonctionnerait pas.
@Michuelnik Vous pouvez dériver la clé publique à partir de la clé privée. Vous ne pouvez pas dériver la clé privée de la clé publique. Nous ne parlons pas du matériel qu'il crypte.
Selon l'endroit où vous obtenez le fichier de clé publique que vous testez, la réponse acceptée peut donner des résultats faussement positifs. Ceci est dû au comportement décrit dans le commentaire de @drewbenn. Plus précisément, lorsque l'option -e est utilisée avec le fichier de clé privée comme paramètre de l'option -f, elle reprend simplement (mais en le reformatant) ce qui se trouve dans le fichier de clé publique associé.
En d'autres termes,
ssh-keygen -y -f id_rsa(apparemment) génère la valeur de la clé publique, et
ssh-keygen -y -e -f id_rsasimplement et sort (et reformate) la clé dans le fichier existant id_rsa.pub quoi qu'il en soit .
Dans mon cas, je dois vérifier que la paire n'a pas été corrompue. J'ai donc décidé de comparer les éléments suivants :
ssh-keygen -y -f id_rsa | cut -d' ' -f 2avec
cut -d' ' -f 2 id_rsa.pubPar conséquent :
diff <(cut -d' ' -f 2 id_rsa.pub) <(ssh-keygen -y -f id_rsa | cut -d' ' -f 2)Cette solution n'est peut-être pas aussi souple, mais elle répond mieux à mes besoins. Peut-être que cela aide quelqu'un d'autre.
Cela devrait vraiment remplacer la réponse acceptée ou au moins la surpasser en termes de votes positifs.
Merci ! Cette commande ne fonctionne pas avec les clés avec une phrase de passe, elle ne le demande pas de manière interactive. J'ai extrait les deux contenus de la commande () dans des fichiers et les ai différenciés, cela fonctionne.
Le plus simple est de comparer les empreintes digitales car les clés publiques et privées sont identiques. La comparaison visuelle est assez facile en mettant les deux commandes sur la même ligne :
ssh-keygen -l -f PRIVATE_KEY; ssh-keygen -l -f PUBLIC_KEYProgrammatiquement, vous voudrez ignorer la partie commentaire, donc
diff -s <(ssh-keygen -l -f PRIVATE_KEY | cut -d' ' -f2) <(ssh-keygen -l -f PUBLIC_KEY | cut -d' ' -f2)
La limite est la même que celle mentionnée dans la réponse ci-dessus : il ne calculera pas l'empreinte digitale à partir de la clé privée si le fichier de clé publique existe. Au lieu de cela, il imprimera simplement l'empreinte digitale de ce qui se trouve dans le fichier de clé publique. Par conséquent, vous pouvez avoir une clé publique différente de la clé privée et le test passera quand même.
Et s'il vous demande toujours un mot de passe ? Les permissions de authorized_keys sont correctes, la clé publique a été copiée correctement dans authorized_keys, j'ai également fait la diff mentionnée dans la réponse vérifiée et les clés vont ensemble.
Cela ne permet pas de répondre à la question. Une fois que vous avez suffisamment réputation vous serez en mesure de commenter un article ; au lieu de cela, fournir des réponses qui ne nécessitent pas de clarification de la part de l'auteur de la question . - De la revue
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
0 votes
Je vais confirmer la réponse de Michuelnik ; cela m'a évité de devoir créer une nouvelle paire de clés, merci.
ssh -vaide aussi beaucoup.