origin example comandos git hook mirroring git-push gitorious

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



git push example (3)

Hay dos métodos que conozco para que pueda especificar cualquier archivo de clave que quiera usar para un sitio de git en la línea de comando de git. No es necesario que codifique este archivo de claves en un archivo de configuración o script. Simplemente proporcione esto directamente en la línea de comando de git.

Método 1: use la variable de entorno GIT_SSH

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

$ PKEY=~/.ssh/keyfile.pem git clone [email protected]:me/repo.git

Para usar este comando, necesita hacer una preconfiguración. 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 ubicación del script de shell anterior.

$ export GIT_SSH=~/ssh-git.sh

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

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

$ chmod +x ~/ssh-git.sh

Ahora puede ejecutar este comando con cualquier archivo de claves que elija usar:

$ PKEY=~/.ssh/keyfile1.pem git clone [email protected]:me/repo.git

Para usar otro archivo de claves para un host diferente:

$ PKEY=~/.ssh/keyfile2.pem git clone [email protected]:other/repo.git

Esto es compatible con cualquier archivo de clave que quiera usar. Cada vez que necesite ejecutar git con un archivo de claves 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 [email protected]:me/repo.git

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

Esto no requiere la configuración previa de un script de shell y GIT_SSH. Solo necesita descargar y ejecutar este script de contenedor único con el comando git.

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

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 repositorio 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 clave ssh para él. Y luego, cuando hago el git push en el gancho post-recepción, asegúrese de que se use esta clave ssh.

Podría usar ~/.ssh/config pero el problema es que muchos usuarios pueden presionar a alioth, y todos tendrían que iniciar sesión y configurar ~/.ssh/config . En cambio, me gustaría tener una opción de línea de comando 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 referencia de git .

GIT_SSH

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

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

Por lo general, es más fácil configurar las opciones deseadas a través de su archivo .ssh/config personal. Consulte su documentación ssh para obtener 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 clave privada (la clave pública está incluida en el script solo como referencia. 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 comando ssh y personalizar known_hosts si lo desea. En este caso de uso, no creo que sea importante.

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 servidor 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 servidor, 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 servidor y no está sujeta a autenticación en el servidor
  • la identidad del ''git push''-er es relevante y está establecida en sistemas que ejecutan el software de alojamiento git en el servidor basado en la clave ssh

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

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

Para la automatización solo se usará la cuenta ''robot'':

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

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

ssh-keygen -f ~/.ssh/id_rsa_robot

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

Paso 4 : Los URI SSH de git en gitorious tienen el formato git @ gitorious.org : prj_or_user / subproject.git . En su archivo ~ / .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 clave 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 clave predeterminada y usará la contraseña (IdentiesOnly "yes").

Paso 5 : Asumiendo que el URI de SSH aplicable para su proyecto es ''[email protected]: project / project.git'', en el repositorio local defina un nuevo ''autopush'' remoto con un nombre de host ligeramente modificado:

git remote add autopush [email protected]:project/project.git

La configuración 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 las llamadas automáticas, se debe generar una clave sin contraseña para la cuenta, pero vincularla a la cuenta de ''desarrollador'' significaría que el trabajo automatizado puede pasar a cualquiera de los proyectos más importantes en los que ''desarrollador'' esté involucrado.