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

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:

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.

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.

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.

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

ssh-add ~/.ssh/id_rsa

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

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.

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.

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.

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 ...

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.

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.

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.)

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 you@youremail.tldet 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 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.

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-----

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.

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.

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).

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.

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