SSH non consente l'uso di una chiave con autorizzazioni leggibili di gruppo


9

Ho un server git di sviluppo che si distribuisce su un server live quando liveviene spinto il ramo. Ogni utente ha il proprio login e quindi l' post-receivehook che esegue la distribuzione live viene eseguito con il proprio utente.

Poiché non voglio mantenere le chiavi pubbliche degli utenti come chiavi autorizzate sul server live remoto, ho creato un set di chiavi che appartengono al sistema git da aggiungere ai server live remoti ( post-receivenell'hook che sto usando $GIT_SSHper impostare la chiave privata con l' -iopzione).


Il mio problema è che a causa di tutti gli utenti che potrebbero voler distribuire per vivere, la chiave privata del sistema git deve essere almeno leggibile dal gruppo e SSH non piace davvero.

Ecco un esempio dell'errore:

XXXX@XXXX /srv/git/identity % ssh -i id_rsa XXXXX@XXXXX
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0640 for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: id_rsa

Mi sono guardato intorno aspettandomi di trovare qualcosa che impedisse a ssh di passare attraverso la connessione, ma non ho trovato altro che gente che dice ciecamente che non dovresti consentire l'accesso a nient'altro che a un singolo utente.

Risposte:


5

Ecco un bel modo semplice e sicuro.

Crea un nuovo utente per il trasferimento ssh, lo chiamerò git-sync. Crea un utente simile sul server con l'appartenenza al gruppo per il repository git. Aggiungi la chiave pubblica per sync-user nel file user_keys2 dell'utente. Suppongo che gli utenti git siano tutti membri del gitgroup. Assicurati che anche l'utente git-sync sia membro di questo gruppo.

Ora modifica il tuo file / etc / sudoers per includere una riga come:

%gitgroup ALL=(git-sync) NOPASSWD: /usr/bin/git

Ciò consentirà a qualsiasi membro del gruppo gitgroup di eseguire il comando / usr / bin / bit come git-sync senza password.

Ora metti qualcosa del genere nel tuo hook post-ricezione:

sudo -u git-sync /usr/bin/git push origin

Questo è meglio di quello che stavo cercando, grazie!
Jessie Ross,

11

È POSSIBILE utilizzare i file di identità leggibili di gruppo, se non sei il proprietario della chiave. Quindi, basta impostare il file di identità di proprietà dell'utente, ad esempio l'utente root e quindi tutti gli utenti del repository git sono impostati per andare.

Un bel vantaggio è che non hai bisogno di sudo: la soluzione sarà più semplice.

Nota che questo si imbatterà nuovamente nel problema originale se stai usando root per eseguire il push sul tuo repository git.


2
Questo è fantastico, e molto meglio delle risposte "non farlo". Grazie!
Ian McGowan il

2
Permissions 0640 for 'id_rsa' are too open.

La chiave privata deve rimanere privata. Non dovresti permettere a nessuno di leggerlo.

Poiché non voglio mantenere le chiavi pubbliche degli utenti come chiavi autorizzate sul server live remoto, ho creato un set di chiavi che appartengono al sistema git da aggiungere ai server live remoti ( post-receivenell'hook che sto usando $GIT_SSHper impostare la chiave privata con l' -iopzione).

  1. imposta una coppia di chiavi su ssh dallo sviluppatore al server di produzione
  2. nello post-receivescript hook, prova qualcosa del genere:

    if [ "live" == "$branch" ]; then
        ssh -t user@prod "git --work-tree=... --git-dir=... checkout -f"
    fi
    

Come posso "impostare una coppia di chiavi su ssh dallo sviluppatore al server di produzione", questo è ciò con cui ho riscontrato un problema. Ne ho già 2 in atto.
Jessie Ross,

1
Sul dev: ssh-keygen, ssh-copy-id user@prod. Sul prod: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys.
quanta,

1
Il problema è che ci sono utenti multipli, quindi devo ripeterlo per ogni utente che vuole modificare i tempi di ogni progetto esistente sul server.
Jessie Ross,

No. Devi solo impostare solo altri due utenti: uno per ssh dallo sviluppatore al prod, e un altro per eseguire il git checkout...(sul prod).
quanta,

Il post-receivehook (dev machine) è gestito dall'utente che sta spingendo un cambiamento (quindi sotto l'autorizzazione degli utenti) in modo che abbiano tutti chiavi diverse, non posso aiutare quale utente sarà. Sono post-receivein azione due hook su due server diversi.
Jessie Ross,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.