Problèmes de déploiement de code avec Capistrano depuis la mise à niveau vers macOS 10.12 (Sierra), «Autorisation refusée (publickey)».
Je viens donc de mettre à jour mon Mac mini (fin 2012) vers macOS 10.12 (Sierra) et tout semble bien, mais je rencontre un problème étrange lors du déploiement de code avec Capistrano . J'obtiens l'erreur suivante:
Permission denied (publickey).
Jamais eu ce problème auparavant dans Mac OS X 10.11 (El Capitan) ou dans une version antérieure. Pourquoi cela se produit-il soudainement maintenant? Sortie complète du déploiement échoué de Capistrano ci-dessous:
jakes_mac:SomeCode jake$ cap staging deploy
INFO [hkdgad21] Running /usr/bin/env mkdir -p /tmp/somecode/ as [email protected]
DEBUG [hkdgad21] Command: /usr/bin/env mkdir -p /tmp/somecode/
[email protected]'s password:
INFO [hkdgad21] Finished in 5.166 seconds with exit status 0 (successful).
DEBUG Uploading /tmp/somecode/git-ssh.sh 0.0%
INFO Uploading /tmp/somecode/git-ssh.sh 100.0%
INFO [xyz20312] Running /usr/bin/env chmod +x /tmp/somecode/git-ssh.sh as [email protected]
DEBUG [xyz20312] Command: /usr/bin/env chmod +x /tmp/somecode/git-ssh.sh
INFO [xyz20312] Finished in 0.240 seconds with exit status 0 (successful).
INFO [abcdef01] Running /usr/bin/env git ls-remote --heads [email protected]:SomeUser/SomeCode.git as [email protected]
DEBUG [abcdef01] Command: ( GIT_ASKPASS=/bin/echo GIT_SSH=/tmp/somecode/git-ssh.sh /usr/bin/env git ls-remote --heads [email protected]:SomeUser/SomeCode.git )
DEBUG [abcdef01] Permission denied (publickey).
DEBUG [abcdef01] fatal: Could not read from remote repository.
DEBUG [abcdef01]
DEBUG [abcdef01] Please make sure you have the correct access rights
DEBUG [abcdef01] and the repository exists.
(Backtrace restricted to imported tasks)
cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as [email protected]: git exit status: 128
git stdout: Nothing written
git stderr: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
SSHKit::Command::Failed: git exit status: 128
git stdout: Nothing written
git stderr: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Tasks: TOP => git:check
(See full trace by running task with --trace)
The deploy has failed with an error: Exception while executing as [email protected]: git exit status: 128
git stdout: Nothing written
git stderr: Permission denied (publickey).
fatal: Could not read from remote repository.
Veuillez vous assurer que vous disposez des droits d'accès appropriés et que le référentiel existe.
Il semble que ce soit un problème avec les clés SSH qui ne sont pas ajoutées automatiquement comme c'était le cas dans Mac OS X 10.11 (El Capitan). Est-ce un comportement attendu de macOS Sierra ou quelque chose de connecté à OpenSSH?
Méthode 1: ajoutez des clés toutes connues à l'agent SSH.
Donc, une solution que j'ai trouvée est d'exécuter ssh-add avec le -A option - qui ajoute toutes les identités connues à l'agent SSH à l'aide de mots de passe stockés dans votre trousseau - comme ceci:
ssh-add -A
Maintenant, cela fonctionne, mais il ne persistera pas lors des redémarrages. Donc, si vous ne voulez plus jamais vous en soucier, ouvrez simplement ~/.bash_profile fichier comme celui-ci:
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 qui se trouvent dans le trousseau à l'agent.
Ainsi, tandis que le ssh-add -A l'option devrait fonctionner pour la plupart des cas de base, j'ai rencontré récemment un problème où j'avais 6-7 boîtes Vagrant (qui utilise des clés/identités SSH pour l'accès) configurées sur une machine en plus de la plus courante 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 des 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 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 de mot de passe.
Le problème est que ssh-add -A ajoutera simplement arbitrairement chaque clé/identité SSH dont vous disposez à l'agent, même si cela n'est pas nécessaire; comme dans le cas des boîtes Vagrant.
Ma solution après de nombreux tests était la suivante.
Tout d'abord, si vous avez ajouté plus de clés/identités SSH à votre agent que nécessaire, comme indiqué avec ssh-add -l puis purgez-les tous de l'agent comme ceci:
ssh-add -D
Cela fait, puis 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.pub clé/identité de l'agent comme ceci:
ssh-add ~/.ssh/id_rsa.pub
Tapez votre phrase secrète, appuyez sur Return et vous devriez être prêt à partir.
Mais dans d'autres cas, il suffit de lancer ceci pour obtenir la clé/identité ajoutée:
ssh-add -K
Si tout a fonctionné, saisissez ssh-add -l et vous devriez voir une seule clé/identité SSH répertoriée.
Tout bon? Ouvrez maintenant votre .bash_profile:
nano ~/.bash_profile
Et ajoutez cette ligne en bas; commenter ou supprimer le -A version si vous l'avez en place:
ssh-add -K
Cela permettra à la clé/identité SSH d'être rechargée sur l'agent SSH à chaque démarrage/redémarrage.
MISE À JOUR 1: Basé sur davidalger la réponse de J'ai découvert une solution globale plus agréable qui peut fonctionner pour tous les utilisateurs d'un système. Ouvrez simplement la configuration globale SSH située ici via Sudo:
Sudo nano /etc/ssh/ssh_config
Et ajoutez cette ligne au bas du fichier:
AddKeysToAgent yes
A fait cela - après avoir supprimé le .bash_profile réparer et tout va bien aussi.
MISE À JOUR 2: Apple a maintenant ajouté une option UseKeychain aux options de configuration SSH ouvertes et considère ssh-add -A une solution également.
Depuis macOS Sierra 10.12.2, Apple (je suppose) a ajouté une option de configuration UseKeychain pour les configurations SSH. 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 voyant la solution soit en ajoutant ssh-add -A à ton .bash_profilecomme expliqué dans ce ticket Open Radar ou en ajoutant UseKeychain comme l'une des options dans un par utilisateur ~/.ssh/config.
Ce comportement est-il attendu de macOS Sierra ou quelque chose de connecté à OpenSSH?
Cela est dû à une nouvelle fonctionnalité d'OpenSSH 7.2 provoquant un changement de comportement de la part du client SSH. À partir de notes de version :
ssh(1): Add an AddKeysToAgent client option which can be set to
'yes', 'no', 'ask', or 'confirm', and defaults to 'no'. When
enabled, a private key that is used during authentication will be
added to ssh-agent if it is running (with confirmation enabled if
set to 'confirm').
D'autres fonctionnalités intéressantes (liées à la sécurité) ont également été introduites, bien que la version ait été considérée principalement comme une version de correction de bogues. Cette fonctionnalité particulière a entraîné un changement de comportement par défaut sous OS X, car sa valeur par défaut est "non" et OS X (je ne connais pas les autres clients) a précédemment ajouté des clés à l'agent lors de leur utilisation.
Donc, si vous ajoutez ce qui suit à votre ~/.ssh/config fichier (ou le global ssh_config qui devrait être situé dans /etc/ssh/ssh_config), les clés seront à nouveau ajoutées à votre agent au fur et à mesure de leur utilisation.
AddKeysToAgent yes
Cette doublure facilite la tâche:
echo "AddKeysToAgent yes" >> ~/.ssh/config
Après cela, j'ai pu obtenir le comportement attendu:
$ ssh-add -l
The agent has no identities.
$ ssh -T [email protected]
logged in as davidalger.
You can use git or hg to connect to Bitbucket. Shell access is disabled.
$ ssh-add -l
2048 SHA256:<snip> (RSA)
Cela m'aide à résoudre le problème sur MacOS Sierra:
eval $(ssh-agent -s)
ssh-add ~/.ssh/id_rsa_file