Le transfert dâagent SSH peut ĂȘtre utilisĂ© pour effectuer le dĂ©ploiement sur un serveur simple. Il vous permet dâutiliser vos clĂ©s SSH locales au lieu de laisser des clĂ©s (sans phrase secrĂšte !) sur votre serveur.
Si vous avez dĂ©jĂ configurĂ© une clĂ© SSH pour interagir avec GitHub, vous ĂȘtes probablement familiarisĂ© avec ssh-agent
. Il sâagit dâun programme qui sâexĂ©cute en arriĂšre-plan et garde votre clĂ© chargĂ©e en mĂ©moire, de sorte que vous nâavez pas besoin dâentrer votre phrase secrĂšte chaque fois que vous devez utiliser la clĂ©. Ce qui est bien câest que vous pouvez choisir de laisser les serveurs accĂ©der Ă votre ssh-agent
local comme sâils sâexĂ©cutaient dĂ©jĂ sur le serveur. Câest comme si vous demandiez Ă un ami dâentrer son mot de passe pour pouvoir utiliser son ordinateur.
Consultez le Guide Tech Tips de Steve Friedl pour obtenir une explication plus dĂ©taillĂ©e du transfert dâagent SSH.
Configuration du transfert dâagent SSH
VĂ©rifiez que votre propre clĂ© SSH est configurĂ©e et fonctionne. Vous pouvez utiliser notre guide sur la gĂ©nĂ©ration de clĂ©s SSH si vous ne lâavez pas encore fait.
Vous pouvez tester le fonctionnement de votre clé locale en entrant ssh -T git@github.com
dans le terminal :
$ ssh -T git@github.com
# Attempt to SSH in to github
> Hi USERNAME! You've successfully authenticated, but GitHub does not provide
> shell access.
Câest bien parti. Configurons SSH pour autoriser le transfert dâagent sur votre serveur.
-
Dans votre éditeur de texte préféré, ouvrez le fichier sur
~/.ssh/config
. Si ce fichier nâexiste pas, crĂ©ez-le en entranttouch ~/.ssh/config
dans le terminal. -
Entrez le texte suivant dans le fichier, en remplaçant
example.com
par le nom de domaine ou lâIP de votre serveur :Host example.com ForwardAgent yes
Avertissement
Vous pouvez ĂȘtre tentĂ© dâutiliser un caractĂšre gĂ©nĂ©rique de type Host *
pour appliquer ce paramĂštre Ă toutes les connexions SSH. Ce nâest pas vraiment une bonne idĂ©e, car dans ce cas vous partagez vos clĂ©s SSH locales avec tous les serveurs sur lesquels vous avez une connexion SSH. Ils nâont alors pas dâaccĂšs direct aux clĂ©s, mais ils peuvent les utiliser comme si câĂ©tait vous pendant lâĂ©tablissement de la connexion. Vous devez uniquement ajouter les serveurs que vous approuvez et que vous voulez utiliser avec le transfert dâagent.
Test du transfert dâagent SSH
Pour tester le transfert dâagent sur votre serveur, vous pouvez ouvrir une connexion SSH sur votre serveur et exĂ©cuter ssh -T git@github.com
une fois de plus. Si tout se passe bien, vous obtenez la mĂȘme invite que celle que vous avez eu localement.
Si vous nâĂȘtes pas sĂ»r que votre clĂ© locale est utilisĂ©e, vous pouvez Ă©galement inspecter la variable SSH_AUTH_SOCK
sur votre serveur :
$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> /tmp/ssh-4hNGMk8AZX/agent.79453
Si la variable nâest pas dĂ©finie, le transfert dâagent ne fonctionne pas :
$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> [No output]
$ ssh -T git@github.com
# Try to SSH to github
> Permission denied (publickey).
RĂ©solution des problĂšmes de transfert dâagent SSH
Voici quelques Ă©lĂ©ments Ă examiner pendant la rĂ©solution des problĂšmes de transfert dâagent SSH.
Vous devez utiliser une URL SSH pour extraire du code
Le transfert SSH fonctionne uniquement avec les URL SSH, et non avec les URL HTTP(S). Consultez le fichier .git/config
sur votre serveur et vĂ©rifiez que lâURL est une URL de type SSH comme ci-dessous :
[remote "origin"]
url = git@github.com:YOUR_ACCOUNT/YOUR_PROJECT.git
fetch = +refs/heads/*:refs/remotes/origin/*
Vos clés SSH doivent fonctionner localement
Pour que vos clĂ©s fonctionnent avec le transfert dâagent, elles doivent dâabord fonctionner localement. Notre guide sur la gĂ©nĂ©ration de clĂ©s SSH peut vous aider Ă configurer vos clĂ©s SSH localement.
Votre systĂšme doit autoriser le transfert dâagent SSH
Parfois, les configurations systĂšme interdisent le transfert dâagent SSH. Vous pouvez vĂ©rifier si un fichier de configuration systĂšme est utilisĂ© en entrant la commande suivante dans le terminal :
$ ssh -v URL
# Connect to the specified URL with verbose debug output
> OpenSSH_8.1p1, LibreSSL 2.7.3
> debug1: Reading configuration data /Users/YOU/.ssh/config
> debug1: Applying options for example.com
> debug1: Reading configuration data /etc/ssh_config
> debug1: Applying options for *
$ exit
# Returns to your local command prompt
Dans lâexemple ci-dessus, le fichier ~/.ssh/config
est chargé en premier, puis /etc/ssh_config
est lu. Nous pouvons inspecter ce fichier pour voir sâil remplace nos options en exĂ©cutant les commandes suivantes :
$ cat /etc/ssh_config
# Print out the /etc/ssh_config file
> Host *
> SendEnv LANG LC_*
> ForwardAgent no
Dans cet exemple, notre fichier /etc/ssh_config
indique spécifiquement ForwardAgent no
, ce qui est un moyen de bloquer le transfert dâagent. La suppression de cette ligne dans le fichier doit permettre de faire fonctionner le transfert dâagent une fois de plus.
Votre serveur doit autoriser le transfert dâagent SSH sur les connexions entrantes
Le transfert dâagent peut Ă©galement ĂȘtre bloquĂ© sur votre serveur. Vous pouvez vĂ©rifier que le transfert dâagent est autorisĂ© en ouvrant une connexion SSH sur le serveur et en exĂ©cutant sshd_config
. La sortie de cette commande doit indiquer que AllowAgentForwarding
est défini.
Votre ssh-agent
local doit ĂȘtre en cours dâexĂ©cution
Sur la plupart des ordinateurs, le systĂšme dâexploitation lance ssh-agent
automatiquement pour vous. Toutefois, sur Windows, vous devez le faire manuellement. Nous avons un guide sur la façon de démarrer ssh-agent
chaque fois que vous ouvrez Git Bash.
Pour vérifier que ssh-agent
sâexĂ©cute sur votre ordinateur, tapez la commande suivante dans le terminal :
$ echo "$SSH_AUTH_SOCK"
# Print out the SSH_AUTH_SOCK variable
> /tmp/launch-kNSlgU/Listeners
Votre clĂ© doit ĂȘtre disponible pour ssh-agent
Vous pouvez vérifier que votre clé est visible pour ssh-agent
en exécutant la commande suivante :
ssh-add -L
Si la commande indique quâaucune identitĂ© nâest disponible, vous devez ajouter votre clĂ© :
ssh-add YOUR-KEY
Conseil
Sur macOS, ssh-agent
« oublie » cette clĂ© chaque fois quâil est redĂ©marrĂ©. Toutefois, vous pouvez importer vos clĂ©s SSH dans le trousseau avec cette commande :
ssh-add --apple-use-keychain YOUR-KEY
Remarque
Lâoption --apple-use-keychain
stocke la phrase secrĂšte dans votre trousseau quand vous ajoutez une clĂ© SSH Ă ssh-agent. Si vous avez choisi de ne pas ajouter de phrase secrĂšte Ă votre clĂ©, exĂ©cutez la commande sans lâoption --apple-use-keychain
.
Lâoption --apple-use-keychain
se trouve dans la version standard de ssh-add
dâApple. Dans les versions macOS antĂ©rieures Ă Monterey (12.0), les indicateurs --apple-use-keychain
et --apple-load-keychain
utilisaient respectivement la syntaxe -K
et -A
.
Si vous nâavez pas la version standard de ssh-add
dâApple installĂ©e, vous pouvez recevoir une erreur. Pour plus dâinformations, consultez « Erreur : ssh-add : option illĂ©gale -- apple-use-keychain ».
Si vous continuez Ă ĂȘtre invitĂ© Ă entrer votre phrase secrĂšte, vous devrez peut-ĂȘtre ajouter la commande Ă votre fichier ~/.zshrc
(ou Ă votre fichier ~/.bashrc
pour bash).