Skip to main content

Cette version de GitHub Enterprise Server n'est plus disponible depuis le 2024-07-09. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

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 Enterprise Server, 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@hostname dans le terminal :

$ ssh -T git@hostname
# 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@hostname 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@hostname
# 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@hostname: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

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