J'ai également eu ce problème lorsque j'ai essayé de déployer du code en utilisant Capistrano . C'est très frustrant. Voici deux méthodes que je connais pour régler ce problème.
Méthode 1 : Ajouter toutes les clés connues à l'agent SSH.
Donc une solution que j'ai trouvée est de lancer ssh-add avec l'option -A - qui ajoute toutes les identités connues à l'agent SSH en utilisant toutes les phrases de passe stockées dans votre porte-clés - comme ceci :
ssh-add -A
Maintenant cela fonctionne mais ne persistera pas lors des redémarrages. Donc si vous ne voulez plus jamais vous inquiéter de cela, ouvrez simplement le fichier ~/.bash_profile de votre utilisateur 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 bien se passer !
Méthode 2 : Ajoutez seulement les clés SSH qui sont dans le trousseau à l'agent.
Donc, alors que l'option ssh-add -A devrait fonctionner pour la plupart des cas de base, j'ai rencontré récemment un problème où j'avais 6-7 boîtes de Vagrant (qui utilise des clés/identités SSH pour l'accès) configurées sur une machine en plus de la id_rsa.pub plus courante en place.
Pour faire court, j'ai fini par être bloqué hors d'un serveur distant à cause de trop d'essais ratés basés sur des 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é toutes 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 va juste ajouter arbitrairement chaque clé/identité SSH que vous avez à l'agent même s'il n'est pas nécessaire de le faire ; comme dans le cas des boîtes Vagrant.
Ma solution, après de nombreux tests, était la suivante.
Premièrement, si vous avez plus de clés/identités SSH ajoutées à votre agent que nécessaire - comme indiqué par ssh-add -l alors purgez-les toutes de l'agent comme cela :
ssh-add -D
Une fois cela fait, démarrez l'agent SSH 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 ajouter spécifiquement la clé/identité ~/.ssh/id_rsa.pub à l'agent de cette façon :
ssh-add ~/.ssh/id_rsa.pub
Tapez votre phrase de passe, appuyez sur Return et vous devriez être prêt à partir.
Mais dans d'autres cas, il suffit d'exécuter cette commande pour que la clé/identité soit ajoutée :
ssh-add -K
Si tout cela fonctionne, tapez ssh-add -l et vous devriez voir apparaître une seule clé/identité SSH.
Tout est bon ? Maintenant, ouvrez votre .bash_profile :
nano ~/.bash_profile
Et ajoutez cette ligne en bas ; commentez ou supprimez la version -A si vous l'avez 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.
UPDATE : Apple a maintenant ajouté une option UseKeychain aux options de configuration SSH ouvertes et considère que ssh-add -A est également une solution.
Depuis la version 10.12.2 de MacOS Sierra, Apple (je suppose) a ajouté une option UseKeychain aux options de configuration SSH. En consultant la page de manuel (via man ssh_config), vous trouverez 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 soit à ajouter ssh-add -A à votre .bash_profile comme expliqué dans ce ticket Open Radar soit à ajouter UseKeychain comme l'une des options dans un ~/.ssh/config par utilisateur.