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.
$ ssh-add -Kme donnessh-add: illegal option -- K