¿Cómo especificar qué key SSH usar dentro de git para git push para tener gitorious como mirror?

Tengo un proyecto alojado en git.debian.org (alioth) y me gustaría configurar un gancho de post-recepción para actualizar un espejo del repository en http://gitorious.org

Supongo que tendré que usar git push --mirror gitorious

Ahora, necesitaré que Alioth haya autorizado a Gitorious para que el empujón tenga éxito. ¿Cómo puedo hacer eso?

Supongo que necesito configurar a un usuario de manera significativa y crear una key ssh para él. Y luego, cuando hago el git push en el gancho post-recepción, asegúrese de que se use esta key ssh.

Podría usar ~/.ssh/config pero el problema es que muchos usuarios pueden presionar a alioth, y todos tendrían que iniciar session y configurar ~/.ssh/config . En cambio, me gustaría tener una opción de línea de command o una variable de entorno para decirle a ssh qué tecla usar. ¿Puedo hacer eso?

Además, ¿tiene otras ideas de cómo se puede lograr la duplicación? Y, ¿es posible configurarlo al revés (empujando a alioth)?

La respuesta se encuentra en el manual de reference de git .

GIT_SSH

Si se configura esta variable de entorno, entonces git fetch y git push usarán este command en lugar de ssh cuando necesiten conectarse a un sistema remoto. El command $GIT_SSH recibirá exactamente dos arguments: el nombre de usuario @ host (o solo el host) de la URL y el command de shell para ejecutar en ese sistema remoto.

Para pasar opciones al progtwig que desea listr en GIT_SSH , deberá ajustar el progtwig y las opciones en un script de shell, luego configure GIT_SSH para hacer reference al script de shell.

Por lo general, es más fácil configurar las opciones deseadas a través de su file .ssh/config personal. Consulte su documentation ssh para get más detalles.

Entonces, necesito escribir un script de contenedor, escribo este script push-gitorious.sh :

 #!/bin/sh if [ "run" != "$1" ]; then exec ssh -i "$GITORIOUS_IDENTITY_FILE" -o "StrictHostKeyChecking 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" <<EOF YOUR SSH PRIVATE KEY EOF cat >"$GITORIOUS_IDENTITY_FILE.pub" <<EOF YOUR SSH PUBLIC KEY EOF #echo git push --mirror "$remote" git push --mirror "$remote" rm -f "$GITORIOUS_IDENTITY_FILE" rm -f "$GITORIOUS_IDENTITY_FILE.pub" exit 0 

Por supuesto, debe completar la key privada (la key pública está incluida en el script solo como reference. También debe completar la URL correspondiente.

En el enlace posterior a la recepción, debes poner:

 path/to/push-gitorious.sh run 

La opción de ejecución es importante; de ​​lo contrario, ejecutará ssh directamente.

Advertencia: no se realiza ninguna verificación en la identidad del host remoto. Puede eliminar la opción de la línea de command ssh y personalizar known_hosts si lo desea. En este caso de uso, no creo que sea importante.

Hay dos methods que conozco para que pueda especificar cualquier file de key que quiera usar para un sitio de git en la línea de command de git. No es necesario que codifique este file de keys en un file de configuration o script. Simplemente proporcione esto directamente en la línea de command de git.

Método 1: use la variable de entorno GIT_SSH

El uso será así en la línea de command:

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

Para usar este command, necesita hacer una preconfiguration. Primero, cree un script de shell con los siguientes contenidos:

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

A continuación, exporte y establezca la variable GIT_SSH con un valor igual a la location del script de shell anterior.

 $ export GIT_SSH=~/ssh-git.sh 

donde ~ / ssh-git.sh es el nombre de file del script de shell anterior.

La secuencia de commands debe ser ejecutable, así que haz una chmod:

 $ chmod +x ~/ssh-git.sh 

Ahora puede ejecutar este command con cualquier file de keys que elija usar:

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

Para usar otro file de keys para un host diferente:

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

Esto es compatible con cualquier file de key que quiera usar. Cada vez que necesite ejecutar git con un file de keys que desee usar, solo bríndelo a la variable PKEY. Puede olvidarse de todo lo demás siempre que GIT_SSH haya sido preconfigurado.

Toma nota de la variable PKEY. Puede usar cualquier nombre siempre que coincida con lo que se utiliza en el script de shell al que apunta GIT_SSH.

Método 2: utilizar un script de envoltura

El uso del script de envoltura será algo como esto:

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

Este uso es intuitivo ya que parece ejecutar ssh con la opción -i.

Esto no requiere la configuration previa de un script de shell y GIT_SSH. Solo necesita download y ejecutar este script de contenedor único con el command git.

Puede get una copy de este script de contenedor aquí: http://alvinabad.wordpress.com/2013/03/23/how-to-specify-an-ssh-key-file-with-the-git-command/

Una alternativa más simple que no involucra ningún script externo es usar un alias SSH. Sé que el cartel original pidió específicamente no cambiar ~ / .ssh / config, pero sospecho que hay un malentendido aquí.

El usuario local en el server no es lo mismo que la persona que hace la confirmación y puede ser una persona diferente a la que hace el 'git push'.

  • en el server, el software de alojamiento puede ejecutarse como un usuario único (generalmente 'git')
  • la identidad de la persona que realiza la confirmación es solo la actividad de git (para agregar a los metadatos de la confirmación), es irrelevante para el server y no está sujeta a authentication en el server
  • la identidad del 'git push'-er es relevante y está establecida en sistemas que ejecutan el software de alojamiento git en el server basado en la key ssh

Por esta razón, en el sistema que realiza el push uno puede forzar una identidad específica incluso para la misma count local y el mismo server remoto, incluso dentro del mismo repository git utilizando un alias ssh siguiendo el método explicado a continuación.

Supongamos que tiene en el server de gitorious.org su count normal, llamémosle 'desarrollador'. No desea presionar automáticamente con su count de "desarrollador" [1] , por lo tanto, cree otra count válida para la synchronization, vamos a llamarla "robot".

Para la automation solo se usará la count 'robot':

Paso 1 : agrega 'robot' al proyecto de Gitorius al que se debe presionar.

Paso 2 : en la máquina local, cree una key sin contraseña (esto se asociará con la count del robot en curso).

 ssh-keygen -f ~/.ssh/id_rsa_robot 

Paso 3 : cargue la key pública ~ / .ssh / id_rsa_robot.pub en gitorious en la count 'robot'.

Paso 4 : Los URI SSH de git en gitorious tienen el formatting git @ gitorious.org : prj_or_user / subproject.git . En su file ~ / .ssh / config agregue las siguientes líneas:

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

Esto se asegurará de que:

  • cada vez que utilice el nombre de host 'robot.gitorious.org' se conectará a gitorious.org (opción HostName),
  • usará la key sin contraseña para autenticarse como robot en gitorius.org (opción IdentiFile) y
  • incluso si tiene un agente ssh en ejecución, ignorará la key pnetworkingeterminada y usará la contraseña (IdentiesOnly "yes").

Paso 5 : Asumiendo que el URI de SSH aplicable para su proyecto es 'git@gitorious.org: project / project.git', en el repository local defina un nuevo 'autopush' remoto con un nombre de host ligeramente modificado:

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

La configuration está hecha, ahora intenta presionar a través del control remoto automático.

 git push autopush master 

Si todo ha ido bien y hay cambios para impulsar, deberías verte empujado exitosamente a 'gitorious.org' como 'robot'

[1] Para los empujes automáticos, se debe generar una key sin contraseña para la count, pero si se adjunta a la count de 'desarrollador' significaría que el trabajo automatizado puede pasar a cualquiera de los proyectos más importantes en los que 'desarrollador' esté involucrado.