230 votes

MacOS Sierra ne semble pas se souvenir des clés SSH entre deux redémarrages

Je dois exécuter cette commande depuis la mise à niveau vers MacOS :

ssh-add -K

Corrige le problème après le redémarrage, mais je dois exécuter cette commande à chaque fois que je me connecte à mon ordinateur.

Si je n'exécute pas la commande ci-dessus, mes clés dans le fichier ~/.ssh sont ignorés et on me demande le mot de passe du serveur afin d'établir la connexion.

1 votes

$ ssh-add -K me donne ssh-add: illegal option -- K

2 votes

Vous devrez entrer le chemin de la clé privée après -K . Voir la réponse de @JakeGould pour la résolution.

0 votes

La mise à jour 10.12.2 a éliminé certaines demandes inutiles de mot de passe de serveur pour moi. Vous n'avez peut-être plus besoin d'exécuter la commande ssh-add -K.

264voto

mluisbrown Points 3834

À partir de MacOS Sierra 10.12.2, Apple a ajouté une fonction ssh_config option appelée UseKeychain ce qui permet une résolution "correcte" du problème. Ajoutez ce qui suit à votre ~/.ssh/config fichier :

Host *
   AddKeysToAgent yes
   UseKeychain yes     

De la ssh_config man sur la page 10.12.2 :

UtiliserKeychain

Sous MacOS, indique si le système doit rechercher les phrases de passe dans le trousseau de l'utilisateur lorsqu'il tente d'utiliser une clé particulière. Lorsque la phrase de passe est fournie par l'utilisateur, cette option indique également si la phrase de passe doit être stockée dans le trousseau une fois que son exactitude a été vérifiée. L'argument doit être 'yes' ou 'no'. La valeur par défaut est 'no'.

0 votes

C'est une bonne astuce, mais en fin de compte ce n'est pas beaucoup mieux que d'ajouter ssh-add -K [path to key] à un .bash_profile puisque les deux méthodes nécessitent un niveau de modification des fichiers par l'utilisateur dans un compte utilisateur qui n'était jamais nécessaire dans le passé pour obtenir la même fonctionnalité.

3 votes

Selon ce lien : openradar.appspot.com/27348363 Apple a "réaligné [son] comportement avec le courant dominant OpenSSH dans ce domaine".

20 votes

Il est absurde qu'Apple ait modifié le comportement d'une manière qui causera des problèmes à la grande majorité des développeurs (à cause du push GitHub, si ce n'est pas autre chose) et n'ait rien dit à personne !

124voto

Giacomo1968 Points 5021

J'ai également rencontré ce problème lorsque j'ai tenté de déployer du code à l'aide de l'outil Capistrano . C'est très frustrant. Voici deux méthodes que je connais pour résoudre ce problème.

Méthode 1 : Ajouter tous connus à l'agent SSH.

Une solution que j'ai trouvée est de lancer ssh-add con el -A qui ajoute toutes les identités connues à l'agent SSH en utilisant toutes les phrases de passe stockées dans votre trousseau comme ceci :

ssh-add -A

Maintenant cela fonctionne mais ne persiste pas à travers les redémarrages. Donc, si vous voulez ne plus jamais vous soucier de cela, ouvrez simplement le dossier de votre utilisateur ~/.bash_profile comme ceci :

nano ~/.bash_profile

Et ajoutez cette ligne en bas :

ssh-add -A 2>/dev/null;

Maintenant, lorsque vous ouvrez une nouvelle fenêtre de Terminal, tout devrait être bon !

Méthode 2 : Ajouter seulement les clés SSH qui sont dans le trousseau de clés à l'agent.

Ainsi, alors que le ssh-add -A devrait fonctionner pour la plupart des cas de base, j'ai rencontré un problème récemment où j'avais 6-7 boîtes Vagrant (qui utilisent des clés/identités SSH pour l'accès) installées sur une machine en plus de l'option plus commune id_rsa.pub en place.

Pour faire court, j'ai fini par être verrouillé sur un serveur distant en raison d'un trop grand nombre d'essais infructueux basés sur les clés/identités SSH, puisque l'accès au serveur était basé sur un mot de passe et que les clés/identités SSH sont des clés/identités SSH. L'agent SSH a donc essayé tous de mes clés SSH, a échoué et je n'ai même pas pu accéder à l'invite du mot de passe.

Le problème est que ssh-add -A ajoutera arbitrairement toutes les clés/identités SSH dont vous disposez à l'agent, même si cela n'est pas nécessaire, comme dans le cas des boîtes Vagrant.

Après de nombreux essais, ma solution a été la suivante.

Tout d'abord, si le nombre de clés/identités SSH ajoutées à votre agent est supérieur à vos besoins, comme le montre l'exemple suivant ssh-add -l puis les purger tous de l'agent comme ceci :

ssh-add -D

Une fois cela fait, démarrez l'agent SSH en tant que processus d'arrière-plan comme suit :

eval "$(ssh-agent -s)"

Maintenant, ça devient bizarre et je ne sais pas trop pourquoi. Dans certains cas, vous pouvez ajouter spécifiquement le ~/.ssh/id_rsa clé/identité à l'agent comme suit :

ssh-add ~/.ssh/id_rsa

Tapez votre phrase de passe, appuyez sur Return et vous devriez être prêt à partir.

Mais dans d'autres cas, il suffit de l'exécuter pour que la clé/identité soit ajoutée :

ssh-add -K

Si tout cela a fonctionné, tapez ssh-add -l et vous devriez voir une seule clé/identité SSH listée.

Tout va bien ? Maintenant, ouvrez votre .bash_profile :

nano ~/.bash_profile

Et ajoutez cette ligne au bas de l'écran ; commentez ou supprimez la ligne -A si vous l'avez mis en place :

ssh-add -K 2>/dev/null;

Cela permettra à la clé/identité SSH d'être rechargée dans l'agent SSH à chaque démarrage/redémarrage.

MISE À JOUR : Apple a maintenant ajouté une UseKeychain aux options de configuration de SSH ouvert et considère que ssh-add -A une solution également.

À partir de MacOS Sierra 10.12.2, Apple a ajouté une UseKeychain option de configuration pour les configurations SSH. En consultant la page de manuel (via man ssh_config ) montre les informations suivantes :

UseKeychain
        On macOS, specifies whether the system should search for
        passphrases in the user's keychain when attempting to use a par-
        ticular key. When the passphrase is provided by the user, this
        option also specifies whether the passphrase should be stored
        into the keychain once it has been verified to be correct.  The
        argument must be ``yes'' or ``no''.  The default is ``no''.

Ce qui revient à dire qu'Apple considère que la solution consiste à ajouter ssh-add -A à votre .bash_profile comme expliqué dans ce ticket Open Radar ou en ajoutant UseKeychain comme l'une des options d'un programme par utilisateur ~/.ssh/config .

0 votes

Cela ne fonctionne pas pour moi, mais j'ai une phrase de passe sur la clé.

4 votes

@modius : si vous avez une clé protégée par un pw, procédez comme suit ssh-add -K [path to key] et entrez pw lorsque vous y êtes invité. Le trousseau stockera le mot de passe et ssh-add le récupérera ensuite.

4 votes

Notez que le -A permet d'ajouter des identités à l'agent en utilisant les phrases de passe stockées dans votre trousseau. Si vous avez également des identités sans phrase de passe, vous devrez omettre l'option -A pour les ajouter à votre agent.

25voto

Comme expliqué aquí il s'agit de la méthode recommandée car MacOS 10.12.2 :

  1. Ajoutez les lignes suivantes à votre ~/.ssh/config fichier :

    Host *
        UseKeychain yes
        AddKeysToAgent yes
  2. Toute clé que vous ajoutez à la ssh-agent en utilisant le ssh-add /path/to/your/private/key/id_rsa sera automatiquement ajouté au trousseau de clés, et devrait être chargé automatiquement au redémarrage.


J'ajoute cette réponse parce que :

  • D'autres réponses vous disent d'ajouter le IdentityFile ~/.ssh/id_rsa mais cette option n'est pas nécessaire pour le chargement automatique des clés (et elle liera cette clé particulière à la section de l'hôte à laquelle vous l'ajoutez, ce que vous ne voudrez pas si vous utilisez des clés différentes pour des hots différents).
  • La réponse acceptée mentionne UseKeychain mais cela n'est pas suffisant pour faire persister les clés dans le fichier ssh-agent après un redémarrage.

3 votes

Concernant le deuxième point. A quel point en êtes-vous sûr ? Rien ne se passe réellement au redémarrage et cela n'est pas mentionné dans votre matériel de référence non plus. Ce qui se passe avec la configuration ci-dessus est que votre client SSH chargera la clé dans l'agent. lors de la première connexion (et il récupérera également la phrase de passe du trousseau), alors la clé restera chargée. Vous pouvez vérifier cette affirmation en listant les clés juste après le redémarrage via ssh-add -L et il rapportera The agent has no identities . Rien ne sera présent jusqu'à ce que vous vous connectiez. Le site AddKeysToAgent ne conserve en aucun cas les clés entre les redémarrages !

16voto

Jirsbek Points 161

J'ai écrit un court article sur ce sujet qui pourrait vous aider.

Une solution consiste à appeler ssh-add -A à chaque démarrage.

Il suffit d'ajouter .plist avec le contenu suivant dans le chemin ~/Library/LaunchAgents/ ou en créer un avec Lingon app :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>ssh-add-a</string>
    <key>ProgramArguments</key>
    <array>
        <string>ssh-add</string>
        <string>-A</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

<!-- @@@@LingonWhatStart:ssh-add -A@@@@LingonWhatEnd -->

8voto

Ben Points 181

Depuis MacOS 10.12.2, vous pouvez utiliser la fonction UseKeychain option. Plus d'informations ici ou regardez dans man ssh_config .

     UseKeychain
         On macOS, specifies whether the system should search for passphrases in the user's keychain
         when attempting to use a particular key. When the passphrase is provided by the user, this
         option also specifies whether the passphrase should be stored into the keychain once it has
         been verified to be correct.  The argument must be ``yes'' or ``no''.  The default is ``no''.

Il suffit donc de faire ce qui suit :

echo "UseKeychain yes" >> ~/.ssh/config

1 votes

Utilisation de >> est en danger si vous saisissez la commande plusieurs fois. Mieux vaut faire une édition manuelle du fichier, comme décrit par réponse de mluisbrown ou Réponse de ChrisJF .

0 votes

Vous avez raison :-)

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X