Skip to main content

Utilisation du transfert d’agent SSH

Pour simplifier le dĂ©ploiement sur un serveur, vous pouvez configurer le transfert de l’agent SSH pour utiliser en toute sĂ©curitĂ© des clĂ©s SSH locales.

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.

  1. Dans votre Ă©diteur de texte prĂ©fĂ©rĂ©, ouvrez le fichier sur ~/.ssh/config. Si ce fichier n’existe pas, crĂ©ez-le en entrant touch ~/.ssh/config dans le terminal.

  2. 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).