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 à l'aide de 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 ppkformat de clé putty private key ( ) avec openssh, cela ne fonctionne pas ... PuTTYgen a une option d'exportation pour openssh si tel 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é autorisé (en ~/.ssh/authorized_keysgénéral).

Une autre hypothèse serait que la clé correcte ne soit pas sélectionnée. Certaines choses que je voudrais essayer sont:

Réinitialiser la phrase secrète en utilisant ssh-keygen, comme ceci ...

$ ssh-keygen -f ~/.ec2/key.ppk -p

Cela confirmera si, en fait, votre clé contient déjà une phrase secrète.

Deuxièmement, j'essaierais de me connecter à l'aide d'une sortie détaillée, en spécifiant explicitement votre clé publique:

$ 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, donc 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, ssh-keygenen générer un nouveau (en veillant à ne pas fournir de phrase secrète), puis partagez la clé public_key dans le fichier authorised_keys sur le serveur auquel vous essayez de vous connecter.

Vous devrez peut-être également supprimer votre ancienne clé de phrase secrète du fichier de clés autorisées sur le serveur auquel vous vous connectez.

Vérifiez que la clé privée id_rsane 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

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.

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.

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é à entrer 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.

Essayez d'afficher les fichiers journaux sur le serveur. Consultez le journal / var / log / auth (par exemple, / var / log / authlog pour OpenSSH, bien que certains systèmes d'exploitation l'utilisent avec Portable OpenSSH et /var/log/auth.log) et vérifiez la fin de ce fichier.

Les causes les plus fréquentes que j'ai observées sont des autorisations incorrectes (comme l'indique la réponse de TD1 ), bien que d'autres problèmes puissent être liés au fait que la clé publique (stockée sur le serveur) ne se trouve pas dans le bon fichier, ou que la clé est mise en commentaire ou 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.

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.