Comment spécifier la clé SSH à utiliser dans git pour git push afin de pouvoir la traiter comme un miroir?

J’ai un projet hébergé sur git.debian.org (alioth) et j’aimerais configurer un hook post-réception pour mettre à jour un miroir du référentiel sur http://gitorious.org

Je suppose que je vais devoir utiliser git push --mirror gitorious

Maintenant, je devrais avoir Alioth autorisé sur gitorious pour la poussée pour réussir. Comment je fais ça?

Je suppose que je dois configurer un utilisateur sur gitorious et créer une clé SSH pour cela. Et puis, lorsque je lance la commande git dans le hook post-réception, assurez-vous que cette clé ssh est utilisée.

Je pourrais utiliser un ~/.ssh/config mais le problème est que de nombreux utilisateurs peuvent utiliser alioth, et tout le monde devrait se connecter et configurer ~/.ssh/config . Au lieu de cela, je voudrais avoir une option de ligne de commande ou une variable d’environnement pour indiquer à ssh la clé à utiliser. Puis-je faire cela?

De plus, avez-vous d’autres idées sur la manière de créer un miroir? Et, est-il possible de le configurer à l’inverse (en poussant les yeux dessus)?

La réponse se trouve dans le manuel de référence de git .

GIT_SSH

Si cette variable d’environnement est définie, alors git fetch et git push utiliseront cette commande au lieu de ssh lorsqu’ils devront se connecter à un système distant. La commande $GIT_SSH recevra exactement deux arguments: le nom d’utilisateur @ host (ou simplement l’hôte) de l’URL et la commande shell à exécuter sur ce système distant.

Pour passer des options au programme que vous souhaitez répertorier dans GIT_SSH vous devrez envelopper le programme et les options dans un script shell, puis définir GIT_SSH pour qu’il se réfère au script du shell.

En général, il est plus facile de configurer les options souhaitées dans votre fichier .ssh/config . Veuillez consulter votre documentation ssh pour plus de détails.

Donc, j’ai besoin d’écrire un script wrapper, j’écris ce script push-gitorious.sh :

 #!/bin/sh if [ "run" != "$1" ]; then exec ssh -i "$GITORIOUS_IDENTITY_FILE" -o "SsortingctHostKeyChecking no" "$@" fi remote=YOUR_SSH_GITORIOUS_URL echo "Mirroring to $remote" export GITORIOUS_IDENTITY_FILE="`mktemp /tmp/tmp.XXXXXXXXXX`" export GIT_SSH="$0" cat >"$GITORIOUS_IDENTITY_FILE" <"$GITORIOUS_IDENTITY_FILE.pub" < 

Bien sûr, vous devez renseigner la clé privée (la clé publique est incluse dans le script à titre de référence uniquement. Vous devez également remplir l'URL pertinente.

Dans le hook post-reception, vous devez mettre:

 path/to/push-gitorious.sh run 

L'option run est importante, sinon elle lancera directement ssh.

Attention: aucune vérification n'est effectuée sur l'identité de l'hôte distant. Vous pouvez supprimer l'option de la ligne de commande ssh et personnaliser known_hosts si vous le souhaitez. Dans ce cas d'utilisation, je ne pense pas que ce soit important.

Les deux méthodes que je connais vous permettent de spécifier n’importe quel fichier de clés que vous souhaitez utiliser pour un site git sur la ligne de commande git. Vous n’avez pas besoin de coder en dur ce fichier de clés dans un fichier de configuration ou un script. Vous fournissez simplement ceci directement à la ligne de commande git.

Méthode 1: utilisez la variable d’environnement GIT_SSH

L’utilisation sera comme ceci sur la ligne de commande:

 $ PKEY=~/.ssh/keyfile.pem git clone git@github.com:me/repo.git 

Pour utiliser cette commande, vous devez effectuer une configuration préalable. Tout d’abord, créez un script shell avec le contenu suivant:

 #!/bin/sh if [ -z "$PKEY" ]; then # if PKEY is not specified, run ssh using default keyfile ssh "$@" else ssh -i "$PKEY" "$@" fi 

Ensuite, exportez et définissez la variable GIT_SSH avec une valeur égale à l’emplacement du script shell ci-dessus.

 $ export GIT_SSH=~/ssh-git.sh 

où ~ / ssh-git.sh est le nom de fichier du script shell ci-dessus.

Le script doit être exécutable, faites un chmod:

 $ chmod +x ~/ssh-git.sh 

Vous pouvez maintenant exécuter cette commande avec n’importe quel fichier de clés que vous choisissez d’utiliser:

 $ PKEY=~/.ssh/keyfile1.pem git clone git@github.com:me/repo.git 

Pour utiliser un autre fichier de clés pour un autre hôte:

 $ PKEY=~/.ssh/keyfile2.pem git clone git@myothersite.com:other/repo.git 

Cela prend en charge tous les fichiers de clés que vous souhaitez utiliser. Chaque fois que vous devez exécuter git avec un fichier de clés que vous souhaitez utiliser, fournissez-le simplement à la variable PKEY. Vous pouvez tout oublier tant que le GIT_SSH a été préconfiguré.

Prenez note de la variable PKEY. Vous pouvez utiliser n’importe quel nom pour autant qu’il corresponde à celui utilisé dans le script shell sur lequel GIT_SSH pointe.

Méthode 2: utiliser un script wrapper

L’utilisation du script wrapper sera quelque chose comme ceci:

 $ git.sh -i ~/.ssh/keyfile.pem clone git@github.com:me/repo.git 

Cette utilisation est intuitive car il ressemble à exécuter ssh avec l’option -i.

Cela ne nécessite pas de pré-configuration d’un script shell et GIT_SSH. Il vous suffit de télécharger et d’exécuter ce script d’encapsulation unique avec la commande git.

Vous pouvez obtenir une copie de ce script wrapper ici: http://alvinabad.wordpress.com/2013/03/23/how-to-specify-an-ssh-key-file-with-the-git-command/

Une alternative plus simple qui n’implique aucun script externe consiste à utiliser un alias SSH. Je sais que l’affiche originale demandait expressément de ne pas changer ~ / .ssh / config, mais je soupçonne qu’il y a un malentendu ici.

L’utilisateur local sur le serveur n’est pas le même que celui qui commet le commit et peut être une personne différente de celle qui effectue le «push».

  • sur le serveur, le logiciel d’hébergement peut fonctionner en tant qu’utilisateur unique (généralement «git»)
  • l’identité de la personne effectuant le commit est uniquement celle de git (pour append aux métadonnées du commit), n’est pas pertinente pour le serveur et n’est pas soumise à l’authentification sur le serveur
  • l’identité de ‘git push’-er est pertinente et est établie sur les systèmes exécutant le logiciel d’hébergement git sur le serveur en fonction de la clé ssh

Pour cette raison, sur le système faisant le push, on peut forcer une identité spécifique même pour le même compte local et le même serveur distant, même dans le même référentiel git en utilisant un alias ssh suivant la méthode expliquée ci-dessous.

Supposons que vous ayez sur le serveur gitorious.org votre compte habituel, appelons-le «développeur». Vous ne voulez pas utiliser automatiquement votre compte «développeur» [1] , vous créez donc un autre compte important pour la synchronisation, appelons-le «robot».

Pour l’automatisation, seul le compte «robot» sera utilisé:

Etape 1 : Ajoutez «robot» au projet gitorius qui doit être poussé.

Étape 2 : Sur la machine locale, créez une clé sans mot de passe (qui sera associée au compte du robot sur gitorious).

 ssh-keygen -f ~/.ssh/id_rsa_robot 

Étape 3 : téléchargez la clé publique ~ / .ssh / id_rsa_robot.pub sur gitorious dans le compte ‘robot’.

Étape 4 : Les URI gh SSH sur gitorious ont le format git @ gitorious.org : prj_or_user / subproject.git . Dans votre fichier ~ / .ssh / config, ajoutez les lignes suivantes:

 host robot.gitorious.org HostName gitorious.org IdentityFile ~/.ssh/id_rsa_robot IdentitiesOnly "yes" 

Cela fera en sorte que:

  • chaque fois que vous utiliserez le nom d’hôte ‘robot.gitorious.org’, il se connectera à gitorious.org (option HostName),
  • il utilisera la clé sans mot de passe pour s’authentifier comme robot sur gitorius.org (option IdentiFile) et
  • Même si vous avez un agent ssh en cours d’exécution, il ignorera la clé par défaut et utilisera la clé sans mot de passe (IdentiesOnly “yes”).

Étape 5 : En supposant que l’URI SSH sur gitorious pour votre projet est ‘git@gitorious.org: project / project.git’, dans le référentiel local, définissez une nouvelle ‘autopush’ distante avec un nom d’hôte légèrement modifié:

 git remote add autopush git@robot.gitorious.org:project/project.git 

La configuration est terminée, essayez maintenant de passer à un niveau raisonnable via la télécommande «autopush».

 git push autopush master 

Si tout s’est bien passé et qu’il y a des changements à faire, vous devriez vous voir propulsé avec succès vers «gitorious.org» en tant que «robot»

[1] Pour les poussées automatiques, une clé sans mot de passe doit être générée pour le compte, mais l’attacher au compte «développeur» signifierait que le travail automatisé peut être envoyé à n’importe quel projet impliquant «développeur».