La boîte de dialogue Mot de passe apparaît lorsque les autorisations de clé privée SSH sont définies sur 0600

71

J'ai installé ma clé privée SSH ~/.ssh/id_rsaet défini ses autorisations sur 0600. Lorsque je me connecte à un serveur SSH qui utilise ma clé privée dans Terminal.app via ssh, une boîte de dialogue s'ouvre et me demande de saisir mon mot de passe pour accéder au id_rsafichier:

entrez la description de l'image ici

La même boîte de dialogue s'affiche lorsque je me connecte à un serveur FTP avec le client Interarchy GUI.

Mise à jour: je vois cette boîte de dialogue chaque fois que je me connecte, que je coche ou non la case "Mémoriser le mot de passe dans mon trousseau". Il apparaît deux fois de plus si le bouton OK est cliqué indépendamment de ce qui est entré dans le champ mot de passe.

Lorsque je relâche ces autorisations pour, par exemple, 0640je ne vois plus de boîte de dialogue me demandant mon mot de passe, mais sshabandonne avec l'erreur suivante:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
@ AVERTISSEMENT: FICHIER DE CLE PRIVEE NON PROTEGE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@
Les autorisations 0640 pour '/Users/myusername/.ssh/id_rsa' sont trop ouvertes.
Il est recommandé que vos fichiers de clé privée ne soient PAS accessibles aux autres.
Cette clé privée sera ignorée.
Bad permissions: ignore la clé: /Users/myusername/.ssh/id_rsa

Je trouve le dialogue sur les mots de passe extrêmement gênant et je suis sûr qu’il doit exister un moyen d’éviter de fermer ce dialogue, ce dont SSH a besoin pour accéder au id_rsafichier.

Remarque: j'utilise Mac OS X 10.6.8.

titaniumdecoy
la source

Réponses:

70

Assurez-vous que vous avez un correspondant id_rsa.pubou id_dsa.pubdans votre ~/.sshrépertoire.

Lorsque j'en avais un, id_rsamais pas un correspondant id_rsa.pub, Mac OS X n'arrêtait pas d'ouvrir la boîte de dialogue et se souvenait que le mot de passe dans mon trousseau ne faisait rien.

cd ~/.ssh
ssh-keygen -y -f id_rsa > id_rsa.pub

généré le fichier de clé publique approprié pour moi.

Si vous aviez déjà votre fichier public là-bas (renommez-le sous un autre nom) et générez à nouveau la clé publique à l'aide de la commande ci-dessus, vous remarquerez que l'ancien et le généré ne sont pas égaux. D'une manière ou d'une autre, les anciennes versions de Mac OS X généraient une clé publique que Lion n'appréciait plus, ce qui corrige sa génération.

Pour les curieux, la clé est exactement la même, la partie qui change est qu'il n'y a plus de section "commentaires" après la clé sur le fichier.

Constantine Sapuntzakis
la source
2
Cette solution n’a peut-être pas beaucoup de sens à première vue, mais essayez-la. J'avais exactement le même problème et cela a été corrigé. J'utilise toujours un mot de passe sur mes clés SSH et vous devriez aussi.
Alex Recarey
3
Cette solution a fonctionné pour moi. Cela n'a aucun sens mais ça marche! (OS X Lion)
bruno077
2
Wow, cela n'a aucun sens, mais cela a certainement corrigé de nombreux comportements étranges sur mon système. Merci.
Warren Pena
2
Pour ma vie, je n'ai pas été en mesure de trouver une solution depuis des jours avec le même problème et cela a résolu le problème pour moi. Cela n’a aucun sens, mais cela a réglé mon problème! Merci, voté.
Danny Englander
Merci OMG! Travaillé pour moi (lion de montagne et utilisation de SourceTree), ces dialogues étaient si ennuyeux.
Sebastian Sastre
91

Tout d’abord, lancez ssh-add -Ket vérifiez si cela résout votre problème.

Si non:

  • Suppression du fichier rsa_id.pub et régénération d'un nouveau fichier (doit être dans ~ / .ssh /):

    ssh-keygen -y -f id_rsa > id_rsa.pub
  • Les autorisations assurées ont été définies sur 600 pour id_rsa et id_rsa.pub (doivent être dans ~ / .ssh /):

    chmod 600 id_rsa*
  • A exécuté la commande suivante:

    ssh-add -K

Après cela, je n'ai plus été invité à donner mon mot de passe de clé privée. Cela semble mettre réellement le mot de passe de la clé privée à l'emplacement correct du trousseau que OS X peut utiliser.

Roseau
la source
7
J'étais en train de devenir fou jusqu'à ce que je rencontre votre commande "ssh-add -K". Je ne crois pas à la complexité d'OSX. +1000
eduncan911
4
fwiw, je devais chmod 600(au lieu de 644) pour que cela fonctionne
kangax
1
La clé privée avec 644 n’est pas un bueno
xtian le
15
ssh-add -Krésolu mon problème
Spechal
2
Ne pas voter jusqu'à ce que chmod 644 soit corrigé en chmod 600, c'est dangereux.
Tomáš Kafka
20

Dans mon cas, ça ssh-add -Kn'a pas marché, il fallait que je spécifie la clé:

ssh-add ~/.ssh/id_rsa
Nathancahill
la source
il n'y a plus d' -Koption. Votre solution a résolu le problème. Je me demande pourquoi j'avais besoin de faire ça. Jamais eu aucune invite de mot de passe.
DannyRe
Merci! C'est alors que OS X Sierra a finalement demandé mon mot de passe id_rsa.
Tomáš Kafka
2
FWIW, le -Kdrapeau a fonctionné pour moi sur Sierra 10.12.2
Chris Wagner
Oui. Je peux confirmer. -K existe et corrige le problème dans la nouvelle Sierra! Bon travail @nathancahill.
Matt Komarnicki
17

Pour macOS 10.12, Sierra ssh-add -Kdoit être exécuté après chaque redémarrage. Pour éviter cela, créez ~/.ssh/configavec ce contenu.

Host *
   AddKeysToAgent yes
   UseKeychain yes
   IdentityFile ~/.ssh/id_rsa

Apple a ajouté la note technique 2449, qui explique ce qui s'est passé.

Avant macOS Sierra, ssh présentait une boîte de dialogue vous demandant votre phrase secrète et vous offrait la possibilité de la stocker dans le trousseau. Cette interface utilisateur a été obsolète il y a quelque temps et a été supprimée.

Edit: Apparemment, spécifier un hôte et une clé n'est pas nécessaire. Il suffit d'ajouter ceci.

AddKeysToAgent yes
UseKeychain yes
Orkoden
la source
C'est ce qui a fonctionné pour moi. Au début, j'ai essayé ssh-add -K, mais la modification ne fonctionnerait que jusqu'au redémarrage.
Gandalf458
Je devais mettre AddKeysToAgentau plus haut niveau de ~/.ssh/config.
Radon Rosborough le
12

Vous devez entrer la phrase secrète de la clé privée quelque part, et OS X utilise ssh-agent par défaut.

Si vous souhaitez utiliser ssh-agent tout en évitant la boîte de dialogue gui, vous pouvez utiliser ssh-add pour ajouter la phrase secrète à l'agent, puis ssh comme d'habitude.

Si vous ne voulez pas utiliser ssh-agent et que vous avez plutôt l'invite ssh pour la phrase secrète, annulez la définition de la variable d'environnement SSH_AUTH_SOCK.

zzz
la source
Merci Alrescha. Savez-vous s'il existe un moyen de stocker votre mot de passe de clé privée dans le trousseau Mac OS X de façon permanente (pas seulement pour une seule session)?
titaniumdecoy
3
Vous pouvez essayer 'ssh-add -K' dans Terminal, mais s'il y a un bogue pour lequel la vérification de la case ne fonctionne pas, cela risque de ne pas fonctionner non plus. Je ne veux pas que mes mots de passe ssh soient stockés dans le trousseau, je n'ai donc pas testé cela.
zzz
Avec ssh-add -KJe n'ai pas entrer mon mot de passe pour se connecter , mais l'invite apparaît encore; Je viens de le rejeter.
titaniumdecoy
3
ssh-add -K est ce que vous utilisez pour ajouter votre mot de passe au trousseau. Si vous n'entrez pas votre mot de passe, il ne pourra pas être mis sur le trousseau.
zzz
1
addendum: Dans Lion et Snow Leopard, si j'entre ssh-add -K, je reçois une invite dans Terminal - pas une boîte de dialogue.
zzz
8

Lorsque vous assouplissez les autorisations, la clé est ignorée. Vous ne gagnerez rien en faisant cela.

Si vous souhaitez utiliser une clé sans avoir à saisir un mot de passe à chaque fois, vous avez deux options.

Si vous cochez la case «Mémoriser le mot de passe dans mon trousseau», vous ne devrez pas taper le mot de passe à chaque fois: il sera stocké dans le trousseau avec tous vos autres mots de passe. C'est l'option recommandée.

Vous pouvez créer un fichier de clé privée sans mot de passe. Vous pouvez modifier votre fichier de clé privée existant de sorte qu'il ne soit pas protégé par mot de passe (la modification du mot de passe affecte uniquement le fichier de clé, pas la clé elle-même). A partir de la ligne de commande, exécutez ssh -p, entrez la phrase secrète existante, puis laissez la nouvelle phrase secrète vide. Le fait de disposer d'une phrase secrète vide présente un risque pour la sécurité: toute personne pouvant accéder à votre fichier de clé privée (par exemple, en accédant à vos sauvegardes) peut l'utiliser instantanément.

Gilles, arrête de faire le mal
la source
Merci pour la réponse, bien que l’une des choses que j’ai oublié de mentionner: la sélection de l’option "Mémoriser le mot de passe dans mon trousseau" n’a aucun effet: la boîte de dialogue réapparaît la prochaine fois que je me connecte. (L'utilisation d'une phrase secrète vide n'est pas une option pour moi.)
titaniumdecoy
3
Suggérer de remplacer une clé protégée par un mot de passe par une clé sans mot de passe est vraiment une idée horrible ...
Schmurfy
5

si vous avez ajouté votre clé privée au répertoire source ~ / .ssh et que vous avez entré ssh-add -K pour l’ajouter au trousseau, et que le contenu de votre clé publique a été copié dans le fichier .ssh / allowed_keys compte) sur le serveur cible, la boîte de dialogue disparaît.

c'est une combinaison délicate de fichiers, autorisations, emplacements et commandes, ce qui peut prendre du temps. Je ne voudrais pas me précipiter pour conclure sur les bugs.

David Griffis
la source
3

J'ai exactement le même problème sur Lion (Mac OS X 10.7). Je pense que c'est un bogue ... Si l'authentification ssh est un mot de passe, le client passe d'abord par la clé publique, ce qui est normal. Cependant, même si vous choisissez d'enregistrer la phrase secrète sur le trousseau (ce qui n'est pas nécessaire pour l'authentification par mot de passe) la prochaine fois qu'une nouvelle connexion ssh est établie, vous êtes à nouveau invité à entrer la phrase secrète ...

Stefan
la source
1
Je considère aussi cela comme un bug, tout fonctionnait bien avec Snow Leopard, mais chaque fois que mon ordinateur revient du mode veille, le mot de passe de la clé ssh est à nouveau demandé, bien que j’ai coché la case "rappelez-le" la dernière fois! Très ennuyeux ...
Schmurfy
3

Il ne devrait pas être nécessaire de régénérer vos clés publiques. Vous pouvez simplement faire ces deux commandes:

chmod 0600 ~/.ssh/id_rsa.pub
ssh-add ~/.ssh/id_rsa

En gros, vous devez resserrer les autorisations sur le fichier de clé publique et ajouter votre clé à l'agent d'authentification OSX.

rouble
la source
3

Dans la dernière version de macOS (10.12.2 - Sierra), cette solution est simple. Editez simplement votre ~ / .ssh / config et activez l'option UseKeychain:

Host *
UseKeychain yes

Enregistrer et résolu.

Ricardo Mendes
la source
2

Ce problème s'est produit sur mon système OS X 10.7.4 à la mort de ssh-agent. Un redémarrage a résolu le problème. (Vous pouvez essayer de redémarrer ssh-agent, mais je ne sais pas si le trousseau est assez intelligent pour prendre le nouveau socket ssh-agent.)

Troy J. Farrell
la source
C’est ce que mon problème a résolu aussi après une dispute d’une heure.
DannyRe
2
  1. Assurez-vous que ~ / .ssh / est chmod 700.

  2. Assurez-vous que les fichiers ~ / .ssh / id * sont tous deux chmod 600.

  3. Exécuter / Applications / Utilitaires / Trousseau Access.app et réparer le trousseau.

  4. Se déconnecter. (Le redémarrage ne serait pas une idée terrible)

  5. S'identifier

  6. Si le problème persiste, déplacez vos fichiers ~ / .ssh / id * existants sur votre bureau et essayez de générer de nouvelles clés à l'aide de ssh-keygen -t dsa -f ~/.ssh/id_dsa -C [email protected]et voyez si les nouvelles clés fonctionnent mieux.

Je suis sur Lion, mais Snow Leopard de l'IIRC a fonctionné de la même manière.

ps - quiconque suggère d'utiliser une phrase secrète ssh vierge devrait être obligé de porter une pancarte afin que les autres utilisateurs sachent qu'ils ne doivent pas suivre leurs conseils.

TJ Luoma
la source
1

La régénération de la clé publique ne semble pas fonctionner pour moi (10.8), pas plus que la génération d'une nouvelle clé SSH. Si, par exemple, je lance git pull après avoir verrouillé le trousseau de connexion, une boîte de dialogue apparaît pour demander le mot de passe de la clé au lieu de tenter de récupérer le mot de passe du trousseau de connexion.

Cependant, si je tue ssh-agent en premier, je suis invité à saisir le mot de passe du trousseau de connexion, qui récupère ensuite le mot de passe de la clé SSH.

blarf
la source
Bonjour, cela ressemble à une question distincte plutôt qu’à une réponse à cette question. Pouvez-vous republier une nouvelle question?
Écossais
1

Une autre découverte intéressante est que si vous copiez et collez le contenu du fichier PEM, il se peut que la fin manque le tiret. Alors rappelez-vous juste d'ajouter la dernière ligne comme,

-----END RSA PRIVATE KEY-----
Croc
la source
Quelque chose de similaire est que lorsque vous collez une clé SSH à partir de quelque chose comme Lastpass, elle colle tout sur une seule ligne. Cela semblait être un problème pour moi, et une fois que la clé privée a été scindée au format approprié, cela a fonctionné.
Cameron Gagnon
1

J'ai dû suivre les étapes suivantes pour que cela fonctionne.

# Change working directory
cd ~/.ssh
# Remove the old public key
rm id_rsa.pub
# Create a new public key
ssh-keygen -y -f id_rsa > id_rsa.pub
# Change permission
chmod 600 id_rsa*
# Add the key to ssh
ssh-add id_rsa
# Then finally test it (I used github)
ssh -i id_rsa.pub git@github.com

La dernière commande devrait alors sortir quelque chose comme: Hi <user>! You've successfully authenticated, but GitHub does not provide shell access.

netbrain
la source
0

J'ai eu le même problème. Je semble avoir résolu le problème en faisant cela.

1) Sauvegardé en renommant les anciens fichiers id_dsa et id_dsa.pub.

2) A couru un nouveau keygen avec un mot de passe vide.

Fonctionne avec le travail périodique launchctl pour surveiller un serveur distant et pour vous connecter à partir de ssh dans un terminal.

J'ai une fonction rapide authme function sur mon terminal puisque j'ai les éléments suivants dans mon fichier .bash_profile

#~/.bash_profile    
function authme {
ssh $1 'cat >>.ssh/authorized_keys' <~/.ssh/id_dsa.pub
}

Donc, un bref authme remoteserver.com copiera la nouvelle clé distante.

Je pense que le bogue a quelque chose à voir avec le mot de passe complexe qui n'a pas été converti (mon ancien Snow Leopard n'en avait pas du tout).

Essaie ça et vois si ça aide.

Cela n'a pas pris plus de 10 minutes à faire. J'ai passé mon temps à googler pour voir s'il y avait d'autres mentions à ce sujet. Ce site était le seul!

Owain.

utilisateur9563
la source
L'utilisation d'un mot de passe vide n'est pas une option pour moi, malheureusement
titaniumdecoy
0

J'ai eu un problème similaire. Il s'est avéré que la clé privée que j'utilisais était dans un mauvais format. J'ai utilisé PuTTY Key Generator sur ma machine Win et ssh sous OS X s'attend à un format différent: le format Open SSH.

Il s'est avéré que l'outil que j'avais utilisé pour générer cette clé (PuTTY Key Generator) avait la possibilité de convertir ma clé privée au format requis par Open SSH.

Simple comme:

  1. Open PuTTY Key Gen
  2. Chargez votre clé privée
  3. Sélectionnez Conversion> Exporter la clé OpenSSH.

Le fichier que vous allez enregistrer contient votre clé privée d'origine au format approprié (OpenSSH).

Greg
la source
0

S'il vous plaît assurez-vous que:

  1. Vous utilisez le format PEM pour votre clé privée. En effet, Mac utilise le client openssh qui fonctionne avec pem. ppk est le format propriétaire de putty et n'est pas compatible avec openssh. Vous pouvez facilement convertir ppk en pem en utilisant putty keygen, au cas où vous n’auriez que ppk.
  2. Les autorisations sur votre fichier pem sont 600. Les clés privées ne sont accessibles que par leur propriétaire. Ainsi, si les autorisations accordent un accès en lecture à une autre personne, cela sera considéré comme une menace pour la sécurité.

Cela devrait, espérons-le, résoudre le problème.

Sasidhar Sekar
la source
-1

Utilisez la clé .pem plutôt que la clé .ppk.

Abhi
la source
1
Nous recherchons des réponses longues qui fournissent des explications et un contexte. Ne vous contentez pas de donner une réponse d'une ligne. expliquez pourquoi votre réponse est juste, idéalement avec des citations. Les réponses qui n'incluent pas d'explications peuvent être supprimées.
Tetsujin