Come specificare quale chiave SSH utilizzare all'interno di git per git push per avere gitorious come mirror?

Question

Ho un progetto ospitato su git.debian.org (alioth) e vorrei configurare un hook post-ricezione per aggiornare un mirror del repository su http://gitorious.org

Suppongo che dovrò usarlo git push --mirror gitorious

Ora, avrò bisogno che Alioth sia autorizzato su Gitorious affinché il push abbia successo.Come lo faccio?

Suppongo di dover configurare un utente su gitorious e creare una chiave ssh per esso.E poi quando eseguo il push git nell'hook post-ricezione, assicurati che venga utilizzata questa chiave ssh.

Potrei usare a ~/.ssh/config ma il problema è che molti utenti possono eseguire il push su alioth e tutti dovrebbero accedere e configurare il file ~/.ssh/config.Mi piacerebbe invece avere un'opzione della riga di comando o una variabile d'ambiente per indicare a ssh quale chiave utilizzare.Posso farlo?

Inoltre, hai altre idee su come ottenere il mirroring?Ed è possibile configurarlo al contrario (spinta gitorious su alioth)?

Answer 1

La risposta è da ricercarsi nel manuale di riferimento git .

  

GIT_SSH

     

Se questa variabile è impostata quindi git fetch e git push utilizzerà questo comando invece di ssh quando hanno bisogno di collegarsi ad un sistema remoto. Il comando $GIT_SSH sarà dato esattamente due argomenti. Username @ host (o solo host) dal URL e il comando shell per eseguire sul sistema remoto

     

Per passare le opzioni al programma che si desidera lista in GIT_SSH dovrete avvolgere il programma e le opzioni in uno script di shell, quindi impostare GIT_SSH per fare riferimento allo script di shell.

     

Di solito è più facile da configurare le opzioni desiderate tramite il file .ssh/config personale. Si prega di consultare la documentazione SSH per ulteriori dettagli.

Così, ho bisogno di scrivere uno script wrapper, scrivo questo 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

Naturalmente, è necessario inserire la chiave privata (la chiave pubblica è incluso nello script solo come riferimento. È inoltre necessario compilare l'URL Gitorious.

Nel post-ricezione gancio, devi mettere:

path/to/push-gitorious.sh run

L'opzione di esecuzione è importante, altrimenti verrà eseguito direttamente ssh.

Attenzione: nessun controllo viene effettuato sull'identità host remoto. È possibile rimuovere l'opzione dalla riga di comando ssh e personalizzare known_hosts se si vuole. In questo caso l'uso, non credo che sia importante.

Answer 2

Ci sono due metodi che conosco in modo che tu possa specificare qualsiasi file di chiavi che desideri utilizzare per un sito git dalla riga di comando git.Non è necessario codificare questo file di chiavi in ​​un file di configurazione o in uno script.Devi semplicemente fornirlo direttamente dalla riga di comando di git.

Metodo 1:Utilizza la variabile di ambiente GIT_SSH

L'utilizzo sarà così sulla riga di comando:

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

Per utilizzare questo comando, è necessario eseguire alcune preconfigurazioni.Innanzitutto, crea uno script di shell con i seguenti contenuti:

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

Successivamente, esporta e imposta la variabile GIT_SSH con un valore uguale alla posizione dello script di shell sopra.

$ export GIT_SSH=~/ssh-git.sh

dove ~/ssh-git.sh è il nome del file dello script di shell sopra.

Lo script deve essere eseguibile quindi esegui un chmod:

$ chmod +x ~/ssh-git.sh

Ora puoi eseguire questo comando con qualsiasi file di chiavi che scegli di utilizzare:

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

Per utilizzare un altro file di chiavi per un host diverso:

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

Questo supporta qualsiasi file di chiavi che desideri utilizzare.Ogni volta che devi eseguire git con un file di chiavi che desideri utilizzare, forniscilo semplicemente alla variabile PKEY.Puoi dimenticare tutto il resto purché GIT_SSH sia stato preconfigurato.

Prendi nota della variabile PKEY.Puoi utilizzare qualsiasi nome purché corrisponda a quello utilizzato nello script di shell a cui punta GIT_SSH.

Metodo 2:Utilizza uno script wrapper

L'utilizzo dello script wrapper sarà simile al seguente:

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

Questo utilizzo è intuitivo poiché sembra che si esegua ssh con l'opzione -i.

Ciò non richiede la preconfigurazione di uno script di shell e GIT_SSH.Devi solo scaricare ed eseguire questo singolo script wrapper con il comando git.

Puoi ottenere una copia di questo script wrapper qui:http://alvinabad.wordpress.com/2013/03/23/how-to-specify-an-ssh-key-file-with-the-git-command/

Answer 3

Un'alternativa più semplice che non comporta alcun script esterni è quello di utilizzare un alias SSH. So che il manifesto originale ha chiesto espressamente di non cambiamento di ~ / .ssh / config, ma ho il sospetto c'è un malinteso.

L'utente locale sul server non è lo stesso che la persona che fa il commit e può essere una persona diversa da quella che fa il 'push git'.

• sul server che ospita il software può essere eseguito come un singolo utente (di solito 'git')
• l'identità della persona che fa il commit è buisness solo di git (da aggiungere a commettere di metadati), è irrilevante per il server e non è soggetta ad autenticazione sul server
• l'identità del 'git push'-er è rilevante ed è stabilito sulla sistemi che eseguono il git software sul server in base alla chiave ssh di hosting

Per questo motivo, il sistema di fare l'unica spinta può forzare una specifica identità anche per lo stesso account locale e lo stesso server remoto, anche all'interno dello stesso repository git utilizzando un alias ssh seguenti utilizzando il metodo spiegato di seguito.

Si supponga di avere sul server gitorious.org tuo account normale, chiamiamolo 'sviluppatore'. Non si vuole spingere automaticamente utilizzando il tuo account 'sviluppatore' [1] , in modo da creare un altro account Gitorious per la sincronizzazione, chiamiamolo 'robot'.

Per l'automazione sarà usato solo l'account 'robot':

Passaggio 1 :. Add 'robot' al progetto gitorius che deve essere spinto a

Passaggio 2 :. Sulla macchina locale creare una chiave paswordless (questo sarà associato all'account robot su Gitorious)

ssh-keygen -f ~/.ssh/id_rsa_robot

Passaggio 3 : caricare la chiave pubblica ~ / .ssh / id_rsa_robot.pub sul Gitorious nel conto 'robot'

.

Passaggio 4 : gli URI SSH git sul Gitorious hanno il formato git @ gitorious.org : prj_or_user / subproject.git . Nel file ~ / .ssh / config aggiungere le seguenti righe:

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

Questo farà in modo che:

• ogni volta che l'utilizzo del nome host 'robot.gitorious.org' si collegherà a gitorious.org (opzione hostname),
• userà la chiave senza password per l'autenticazione come robot su gitorius.org (IdentiFile opzione) e
• , anche se si dispone di un agente ssh in esecuzione, ignorerà la chiave predefinita e utilizzare il passwordless una (IdentiesOnly "sì").

Passaggio 5 : Supponendo che l'URI SSH sul Gitorious per il vostro progetto è 'git@gitorious.org: progetto / project.git', nel repository locale definire un nuovo telecomando 'autopush' con un leggermente modificato il nome host:

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

Il setup è stato fatto, ora provare a spingere al Gitorious attraverso il 'autopush' a distanza.

git push autopush master

Se tutto è andato bene e non ci sono cambiamenti di spingere, si dovrebbe vedere voi con successo spinto a 'gitorious.org' come 'robot'

[1] Per spinte automatiche una chiave senza password deve essere generata per l'account, ma collegandolo al conto Gitorious 'autore' significherebbe che il lavoro automatizzato può spingere su qualsiasi progetti gitourious dove 'developer' è coinvolto in Gitorious.