macOS Sierra ne semble pas se souvenir des clés SSH entre les redémarrages

185

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 ~/.sshsont ignorées et on me demande le mot de passe du serveur pour établir la connexion.

bisherbas
la source
1
$ ssh-add -Kme donnessh-add: illegal option -- K
Modius
1
Vous devrez entrer le chemin de la clé privée après -K. Voir la réponse de @JakeGould pour la résolution.
bisherbas
La mise à jour 10.12.2 a éliminé pour moi certaines requêtes de mot de passe serveur superflues. Vous n’avez peut-être plus besoin de lancer ssh-add -K.
Wayfaring Stranger

Réponses:

216

À partir de macOS Sierra 10.12.2, Apple a ajouté une ssh_configoption appelée UseKeychainqui permet une résolution «appropriée» du problème. Ajoutez ce qui suit dans votre ~/.ssh/configfichier:

Host *
   AddKeysToAgent yes
   UseKeychain yes     

De la ssh_config manpage du 10.12.2:

UseKeychain

Sous macOS, spécifie si le système doit rechercher des phrases secrètes dans le trousseau de l'utilisateur lorsqu'il tente d'utiliser une clé particulière. Lorsque la phrase secrète est fournie par l'utilisateur, cette option spécifie également si la phrase secrète doit être stockée dans le trousseau une fois qu'il a été vérifié qu'il est correct. L'argument doit être «oui» ou «non». La valeur par défaut est "non".

mluisbrown
la source
2
Selon ce lien: openradar.appspot.com/27348363 Apple a "réaligné son comportement avec le courant dominant OpenSSH dans ce domaine".
ThomasW
15
Il est absurde qu'Apple ait modifié le comportement de manière à causer des problèmes à la grande majorité des développeurs (à cause de GitHub push si rien d'autre) et à ne rien dire à personne!
mluisbrown
9
Je pense que le IdentityFile ~/.ssh/id_rsaest redondant et n'est pas nécessaire (quand on regarde les options par défaut). Je n'ai jamais défini cette option dans mon fichier de configuration ssh.
therealmarv
9
@JakeGould IMO changer ~/.ssh/config~est préférable car cela résout le problème au sshniveau. Pas tout à fait sûr que le .bash_profilemod fonctionnera pour les clients GUI utilisant ssh sans utiliser de shell.
mluisbrown
7
Apple a publié la note technique TN2449 concernant ce changement.
Kentzo
107

J'avais également ce problème lorsque je tentais de déployer du code avec Capistrano . Très frustrant. Je connais deux méthodes pour régler ce problème.

Méthode 1: ajoutez toutes les clés connues à l'agent SSH.

Une solution que j’ai trouvée est donc de fonctionner ssh-addavec l’ -Aoption — qui ajoute toutes les identités connues à l’agent SSH à l’aide des phrases secrètes stockées dans votre trousseau — comme ceci:

ssh-add -A

Maintenant, cela fonctionne mais cela ne persistera pas lors des redémarrages. Donc, si vous ne souhaitez plus jamais vous inquiéter à ce sujet, ouvrez simplement le ~/.bash_profilefichier de votre utilisateur comme suit:

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: ajoutez uniquement les clés SSH figurant dans le trousseau à l'agent.

Ainsi, bien que l’ ssh-add -Aoption devrait fonctionner dans la plupart des cas élémentaires, j’ai rencontré récemment un problème dans lequel j’avais 6-7 boîtes Vagrant (qui utilise des clés / identités SSH pour l’accès) installées sur une machine plus répandue id_rsa.pub.

Bref, j'ai été bloqué sur un serveur distant à cause d'un trop grand nombre d'essais infructueux basés sur les clés / identités SSH, car l'accès au serveur était basé sur un mot de passe et les clés / identités SSH étaient des clés / identités SSH. Donc, l'agent SSH a essayé toutes mes clés SSH, a échoué et je n'ai même pas pu accéder à l'invite de mot de passe.

Le problème est que nous ssh-add -Aallons ajouter arbitrairement chaque clé / identité SSH que vous avez à l'agent, même si cela n'est pas nécessaire. comme dans le cas des boîtes vagabondes.

Ma solution après de nombreux essais était la suivante.

Tout d'abord, si vous avez ajouté plus de clés / identifiants SSH à votre agent que nécessaire - comme indiqué, ssh-add -lpurgez-les tous de l'agent comme suit:

ssh-add -D

Ceci fait, démarrez l’agent SSH en tant que processus en 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 spécifiquement ajouter la ~/.ssh/id_rsaclé / identité à l'agent de la manière suivante:

ssh-add ~/.ssh/id_rsa

Tapez votre phrase secrète, appuyez sur Returnet vous devriez être prêt à partir.

Mais dans d’autres cas, il suffit d’exécuter cela pour obtenir la clé / identité ajoutée:

ssh-add -K

Si cela fonctionne, tapez ssh-add -let vous devriez voir une seule clé / identité SSH répertoriée.

Tout bon? Maintenant ouvrez votre .bash_profile:

nano ~/.bash_profile

Et ajoutez cette ligne en bas; commentez ou supprimez la -Aversion si cela est en place:

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

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

MISE À JOUR: Apple a maintenant ajouté une UseKeychainoption aux options de configuration SSH ouvertes et envisage également ssh-add -Aune solution.

À partir de macOS Sierra 10.12.2, Apple a ajouté une UseKeychainoption de configuration pour les configurations SSH. La vérification de la page de manuel (via man ssh_config) affiche 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 à Apple à voir la solution soit en ajoutant ssh-add -Aà votre .bash_profile comme expliqué dans ce ticket Open Radar, soit en ajoutant l’ UseKeychainune des options dans chaque utilisateur ~/.ssh/config.

JakeGould
la source
4
@modius: si vous avez une clé protégée pw, ssh-add -K [path to key]saisissez-la et entrez pw lorsque vous y êtes invité. Keychain stockera le mot de passe et ssh-add l'obtiendra à partir de là.
Timo
2
Notez que l'option -A permet d'ajouter des identités à l'agent à l'aide des phrases secrètes stockées dans votre trousseau. Si vous avez en outre des identités sans phrase secrète, vous devrez omettre l'option -A pour les ajouter à votre agent.
Evan Pon
12
Juste pour ajouter un peu plus de visibilité à cela, Apple a mis à jour la page de manuel de ssh_config à inclure UseKeychainet AddKeysToAgentà ajouter automatiquement vos clés à partir de votre ssh_config. Aucun script shell nécessaire. Voir la réponse @mluisbrown ci-dessous pour les informations mises à jour pour 10.12.2
Ryan Gibbons
1
@JakeGould je comprends ce que vous dites, j'aime vraiment ce qu'ils font. Au lieu de sauvegarder automatiquement la phrase secrète dans le trousseau et de le charger au démarrage, ils vous permettent de contrôler votre sécurité. / haussement d'épaules
Ryan Gibbons
1
@RyanGibbons FWIW, observez la suggestion officielle d' Apple Developer Relations dans cette réponse à OpenRadar: "Vous pouvez résoudre ce problème assez facilement en exécutant ssh-add -Avotre script rc si vous souhaitez que vos clés soient toujours chargées." ¯\_(ツ)_/¯
JakeGould
16

Comme expliqué ici , voici la méthode recommandée depuis macOS 10.12.2 :

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

    Host *
        UseKeychain yes
        AddKeysToAgent yes
  2. Toute clé que vous ajoutez à ssh-agent à l'aide de la ssh-add /path/to/your/private/key/id_rsacommande sera automatiquement ajoutée au trousseau et devrait être chargée automatiquement au redémarrage.


J'ajoute cette réponse parce que:

  • D’autres réponses vous suggèrent d’ajouter la IdentityFile ~/.ssh/id_rsaligne, mais cette option n’est pas nécessaire pour le chargement automatique des clés (elle liera cette clé à la section hôte à laquelle vous l’ajoutez, ce que vous ne voudrez pas utiliser si vous utilisez des clés différentes hots différents).
  • La réponse acceptée mentionne UseKeychain, mais cela ne suffit pas pour conserver les clés ssh-agentaprès un redémarrage.
Ricardo Sanchez-Saez
la source
1
Concernant le deuxième point. À quel point êtes-vous sûr? Rien ne se produit réellement au redémarrage et cela n’est pas mentionné dans vos documents de référence. Ce qui se passe avec la configuration ci-dessus, c'est que votre client SSH chargera la clé dans l'agent lors de la première connexion (et extraira également la phrase secrète du trousseau), puis la clé restera chargée. Vous pouvez vérifier cette déclaration en énumérant les clés juste après le redémarrage via ssh-add -Let il fera rapport The agent has no identities. Rien ne sera là jusqu'à ce que vous vous connectez. Les AddKeysToAgentclés ne persistent pas entre les redémarrages en aucune façon!
Danila Vershinin
15

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

Une solution appelle une ssh-add -Acommande à chaque démarrage.

Ajoutez simplement un .plistfichier avec le contenu suivant au chemin ~/Library/LaunchAgents/ou créez-en un avec l' application Lingon :

<?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 -->
Jirsbek
la source
8

Depuis macOS 10.12.2, vous pouvez utiliser cette UseKeychainoption. Lire plus ici ou regarder 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

Ben
la source
1
L'utilisation >>est à risque si vous entrez la commande plusieurs fois. Mieux vaut faire une édition manuelle du fichier, comme décrit par mluisbrown answer ou ChrisJF answer .
Cœur
Vous avez raison :-)
Ben
4

J'ai trouvé que cela ssh-add -Kme donnait " option illégale - K ". C'était parce que ssh-add était une version étrange provenant de / usr / local / bin (installé par brew?). J'ai pu ajouter la clé par utilisation spécifique de ssh-add situé dans / usr / bin:

/usr/bin/ssh-add -K ~/.ssh/id_rsa
Fiskabollen
la source
C’est ce qui a bien fonctionné pour moi après avoir échoué à travailler facilement pendant des siècles.
Nyxee
4

J'ai déjà eu ce problème et j'ai trouvé un moyen de le contourner. Je viens de créer un fichier nommé configdans mon ~/.sshdossier, dans lequel j'ai ajouté les lignes suivantes:

Host github.com
HostName github.com
IdentityFile ~/.ssh/github
IdentitiesOnly yes

Je ne sais pas pourquoi, mais Hostet les HostNamedeux sont importants. Dans mon cas, si l'un d'entre eux n'était pas présent, la solution ne fonctionnait pas.

Ensuite, je viens de faire un ssh-add -Ket cela fonctionnait même après le redémarrage.

Infini
la source
1
Host est votre nom / alias défini par l'utilisateur pour un serveur particulier et délimite les entrées par serveur: stylistiquement, il est agréable d'indenter les lignes qui suivent l'entrée Host. HostName indique le nom d'adresse réseau du serveur, tel que github.com, mais vous pouvez également utiliser une adresse IP. Host et HostName n'ont pas besoin d'être identiques, mais ils font tous deux partie intégrante du format de configuration ssh.
Mark Fox
4

Si vous utilisez une version différente de ssh (par exemple, installée via homebrew), les solutions ci-dessus ne fonctionneront pas. Par exemple, AddKeysToAgent yeset UseKeychain yesdans le .ssh/configfichier ne sont pas reconnus par les versions non-Apple ssh et provoqueront une erreur. La même chose pour l' option -Aou -Kpour le sshclient.

Cela signifie que la réponse de @mluisbrown ne fonctionnera pas du tout. Vous pouvez utiliser la méthode 1 de la réponse de @JakeGould et utiliser explicitement l' ssh-addutilitaire macOS dans votre .bash_profilepour ajouter toutes les clés au trousseau, à savoir:

/usr/bin/ssh-add -A

Comme mentionné dans un commentaire ci - dessus , vous devrez peut-être ajouter une clé au trousseau:/usr/bin/ssh-add -K .ssh/github

n1000
la source
2

Modifier ~ / .ssh / config pour ajouter UseKeyChain à tous les hôtes suffit à mettre fin à ce cauchemar récurrent;)

Host *
 UseKeychain yes

Si le fichier est vide ou n’existe pas, créez et / ou ajoutez la configuration ci-dessus.

chim
la source
1

J'ai mis à jour pour Mac OS X Sierra (10.12.6). Je pourrais SSH dans d'autres hôtes mais pas dans github.com.

C'est ce que je devais insérer dans ~ / .ssh / config:

PubkeyAcceptedKeyTypes ssh-dss,ssh-rsa

Après ce changement, je pourrais utiliser github comme avant.

Matthias Bohlen
la source