La clé SSH me demande un mot de passe?
J'ai une paire de clés publique/privée. Ni l'un ni l'autre ne sont associés à une phrase secrète.
Chaque fois que j'essaie d'utiliser SSH en utilisant le privé ou le public (et je suis presque sûr que je ne devrais utiliser que la clé publique), on me demande une phrase secrète et, bien sûr, je ne peux pas me connecter.
Quelqu'un a une idée de comment contourner cela? Est-ce que je tape une commande de manière incorrecte? J'essaie de ssh sur un serveur que j'ai configuré dans mon fichier ~/.ssh/config (correctement, car cette même installation fonctionne sur un autre serveur) avec la clé stockée dans ~/.ec2/key.ppk
J'ai également essayé d'utiliser puttygen.exe pour générer une nouvelle clé privée AVEC une phrase secrète, puis avec cette clé. Lorsque je tape la phrase secrète, elle échoue toujours.
Tout d’abord, c’est la clé privée qui aura la phrase secrète. Cela valide par rapport à la clé publique stockée sur le serveur distant.
La meilleure hypothèse est que vous essayez d'utiliser un format de clé de clé privée PuTTY (ppk) avec openssh, cela ne fonctionne pas .... PuTTYgen a une option d'exportation pour openssh si c'est le cas.
ssh-rsa AAAAB3NzaC1y...... etc
Je suppose également que le serveur sur lequel vous essayez de ssh a votre clé publique correctement stockée dans le fichier de clés autorisé (dans ~/.ssh/authorized_keys généralement).
Une autre hypothèse serait que la clé correcte ne soit pas sélectionnée. Certaines choses que je voudrais essayer sont:
Réinitialisation de la phrase secrète en utilisant ssh-keygen, comme ceci ...
$ ssh-keygen -f ~/.ec2/key.ppk -p
Cela confirmera si votre clé est déjà dotée ou non d'une phrase secrète.
Deuxièmement, j'essaierais de me connecter en utilisant une sortie détaillée, en spécifiant explicitement votre clé publique en sortie:
$ ssh Host -i ~/.ec2/key.ppk -vvv
Cela vous donnera plus d'une idée de ce qui se passe.
Vous pouvez exécuter ssh-agent. Voir ici pour une discussion.
La version courte qui a fonctionné pour moi (en bash):
$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-rnRLi11880/agent.11880; export SSH_AUTH_SOCK;
SSH_AGENT_PID=11881; export SSH_AGENT_PID;
echo Agent pid 11881;
J'ai pris les 3 lignes qui résonnent et les ai exécutées. Une autre façon de faire est de prendre le résultat de -s:
$ eval `ssh-agent -s`
Ensuite, j'ai ajouté mes informations d'identification:
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/me/.ssh/id_rsa:
Identity added: /home/me/.ssh/id_rsa (/home/me/.ssh/id_rsa)
Maintenant, l'agent fournit les informations d'identification au lieu de me demander de saisir mon mot de passe complexe.
Je pense que ssh-agent disparaît quand le shell le fait, alors cela devrait être écrit au démarrage pour un maximum de confort. Le lien que j'ai partagé décrit également les scripts.
Lorsque vous configurez votre clé publique, vous la configurez probablement (peut-être par inadvertance) avec une phrase secrète.
Vous devez probablement recommencer à zéro - je n'ai pas utilisé puttygen, mais vous pouvez supprimer (ou renommer) la clé publique de votre répertoire .ssh, utiliser ssh-keygen pour en générer un nouveau (en veillant à ne pas fournir de phrase secrète), et puis partagez la clé public_key dans le fichier allowed_keys du serveur auquel vous essayez de vous connecter.
Vous devrez peut-être également supprimer votre ancienne clé de mot de passe complexe du fichier de clés autorisées sur le serveur auquel vous vous connectez.
Une chose à vérifier, si votre fichier sshd_config a StrictModes = yes, le répertoire $ HOME ou le répertoire $ HOME/.ssh ne doit pas être accessible en écriture au groupe ni à un autre. Sinon, l'authentification échoue quoi qu'il arrive.
Vérifiez que la clé privée id_rsa ne comporte pas de sauts de ligne supplémentaires à la fin. Dans certains cas, des sauts de ligne supplémentaires obligeront ssh-keygen à demander la phrase secrète. Essayez ceci:
sed '/^$/d' /path/to/key > id_rsa
tester:
ssh-keygen -yf id_rsa
J'ai commis l'erreur d'écraser accidentellement mon fichier ~/.ssh/id_rsa avec mon ~/.ssh/id_rsa.pub. Ce faisant, ssh demandera une phrase de passe.
Essayez d'afficher les fichiers journaux sur le serveur. Voir/var/log/ auth log (par exemple,/var/log/authlog pour OpenSSH, bien que certains systèmes d’exploitation utilisent Portable OpenSSH et utilisent/var/log/auth.log) et vérifiez la fin de ce fichier.
Les causes les plus courantes que j'ai observées sont des autorisations incorrectes (comme indiqué par la réponse de TD1 ), bien que d'autres problèmes puissent être liés à la clé publique (stockée sur le serveur principal). serveur) n’étant pas dans le bon fichier, ni la clé en commentaire, ni un nom d’utilisateur mal orthographié.
Il peut également être utile (pour le dépannage) de donner temporairement une phrase secrète au compte, juste pour vérifier que le compte peut être connecté avec succès lorsque vous le faites.
Si l'affichage du fichier journal ne vous conduit pas rapidement à une résolution, je suggère de poser une nouvelle question (puisqu'il s'agit d'une excellente question généralisée), qui inclut les détails spécifiques du fichier journal, de sorte que des instructions plus précises puissent être fournies.
J'ai rencontré ce problème l'autre jour. Plus précisément, j'essayais de copier/coller une clé AWS privée d'une machine à une autre.
J'ai la mauvaise habitude de rater le premier ou le dernier caractère. Il s'avère que si vous ne saisissez pas chaque trait d'union à la fin de votre clé privée, même si cela n'a rien à voir avec le texte de la clé elle-même, vous serez invité à saisir une phrase secrète pour la clé privée jusqu'à ce que tous les caractères de la clé soient ajoutés. clé à partir de laquelle vous avez copié (dans mon cas, cela signifiait l’ajout d’un trait d’union à la fin de la clé).
Je suppose que cela signifie que la meilleure pratique consiste à SSH le fichier texte sur le réseau au lieu d'essayer de copier et coller entre les fenêtres du terminal.
Sur OSX, je pouvais simplement exécuter:
$ ssh-add ~/.ssh/id_rsa Enter passphrase for /Users/me/.ssh/id_rsa: `Identity added: /Users/mikekilmer/.ssh/id_rsa (/Users/mikekilmer/.ssh/id_rsa)
Le mot de passe a été stocké par l'application Keychain Access, située dans le dossier Applications> Utilitaires. Je viens d'entrer id_ dans le champ de recherche.
Dans mon équipe, lorsque cela se produit, ce n'est pas un problème localement. La clé et/ou l'accès ssh de l'utilisateur n'ont pas été configurés correctement sur le serveur auquel ils se connectent (dans notre cas, une plate-forme d'hébergement). Pour une raison quelconque, cela déclenche une invite pour une clé ssh non existante.