J'ai installé ma clé privée SSH ~/.ssh/id_rsa
et 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_rsa
fichier:
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, 0640
je ne vois plus de boîte de dialogue me demandant mon mot de passe, mais ssh
abandonne 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_rsa
fichier.
Remarque: j'utilise Mac OS X 10.6.8.
la source
Tout d’abord, lancez
ssh-add -K
et 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 /):
Les autorisations assurées ont été définies sur 600 pour id_rsa et id_rsa.pub (doivent être dans ~ / .ssh /):
A exécuté la commande suivante:
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.
la source
chmod 600
(au lieu de 644) pour que cela fonctionnessh-add -K
résolu mon problèmeDans mon cas, ça
ssh-add -K
n'a pas marché, il fallait que je spécifie la clé:la source
-K
option. 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.-K
drapeau a fonctionné pour moi sur Sierra 10.12.2Pour macOS 10.12, Sierra
ssh-add -K
doit être exécuté après chaque redémarrage. Pour éviter cela, créez~/.ssh/config
avec ce contenu.Apple a ajouté la note technique 2449, qui explique ce qui s'est passé.
Edit: Apparemment, spécifier un hôte et une clé n'est pas nécessaire. Il suffit d'ajouter ceci.
la source
AddKeysToAgent
au plus haut niveau de~/.ssh/config
.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.
la source
ssh-add -K
Je n'ai pas entrer mon mot de passe pour se connecter , mais l'invite apparaît encore; Je viens de le rejeter.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.la source
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.
la source
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 ...
la source
Il ne devrait pas être nécessaire de régénérer vos clés publiques. Vous pouvez simplement faire ces deux commandes:
En gros, vous devez resserrer les autorisations sur le fichier de clé publique et ajouter votre clé à l'agent d'authentification OSX.
la source
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:
Enregistrer et résolu.
la source
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.)
la source
Assurez-vous que ~ / .ssh / est chmod 700.
Assurez-vous que les fichiers ~ / .ssh / id * sont tous deux chmod 600.
Exécuter / Applications / Utilitaires / Trousseau Access.app et réparer le trousseau.
Se déconnecter. (Le redémarrage ne serait pas une idée terrible)
S'identifier
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.
la source
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.
la source
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,
la source
J'ai dû suivre les étapes suivantes pour que cela fonctionne.
La dernière commande devrait alors sortir quelque chose comme:
Hi <user>! You've successfully authenticated, but GitHub does not provide shell access.
la source
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
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.
la source
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:
Le fichier que vous allez enregistrer contient votre clé privée d'origine au format approprié (OpenSSH).
la source
S'il vous plaît assurez-vous que:
Cela devrait, espérons-le, résoudre le problème.
la source
Utilisez la clé .pem plutôt que la clé .ppk.
la source