Ho un server git su ssh e ogni utente ha un account unix sul sistema.

Dato che due utenti hanno accesso a un repository, come posso essere sicuro di quale utente ha eseguito quale commit, poiché il nome utente e l'e-mail di commit sono inviati e controllati dal client git.

Temo che un utente possa tentare di impersonare un altro, anche se hanno gli stessi diritti di autorizzazione.

Se sei così preoccupato, ci sono un paio di modi per affrontare il problema.

1. Fai firmare ai tuoi utenti i tuoi commit, c'è il supporto per la firma GPG.
2. Non dare agli utenti il ​​diritto di impegnarsi nel repository principale, farli impegnare nel proprio repository e quindi fare in modo che un utente fidato porti le modifiche nel repository principale. Ecco perché se guardi i messaggi di log di alcuni progetti git (come git stesso) vedrai che sono campi separati per "Autore", la persona che ha creato la modifica. e "Committer": la persona che ha commesso la modifica nel repository.

Vedo due buoni modi per ottenere questo tipo di informazioni. Uno è aumentando la registrazione da sshd stesso e l'altro facendo un monitoraggio più approfondito del repository git su disco. Dal momento che nessuno dei due ti fornisce individualmente le informazioni che desideri, potresti voler fare entrambe le cose e correlare i dati di registro usando un motore di analisi dei registri esterno o, su richiesta, usando occhi umani e timestamp.

Modifiche sshd

Per impostazione predefinita, come hai sicuramente visto, puoi vedere quando un utente ha effettuato l'accesso e da dove, utilizzando i log di autenticazione ssh. Quello che vuoi fare è cambiare il livello quando esci da sshd. Quindi modifica il tuo /etc/ssh/sshd_confige trova la linea che sembra

#LogLevel INFO

e cambiarlo in

LogLevel VERBOSE

quindi riavviare il servizio sshd. Ciò aumenta il livello di registrazione di sshd di 1 passaggio, il che fornisce molte più informazioni. Dai un'occhiata a questo frammento di registro del mio accesso remoto dopo aver apportato quella modifica.

Nov  2 08:37:09 node1 sshd[4859]: Connection from 10.10.10.5 port 50445
Nov  2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov  2 08:37:10 node1 sshd[4860]: Postponed publickey for scott from 10.10.10.5 port 50445 ssh2
Nov  2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov  2 08:37:10 node1 sshd[4859]: Accepted publickey for scott from 10.10.10.5 port 50445 ssh2
Nov  2 08:37:10 node1 sshd[4859]: pam_unix(sshd:session): session opened for user scott by (uid=0)
Nov  2 08:37:10 node1 sshd[4859]: User child is on pid 4862
Nov  2 08:40:27 node1 sshd[4862]: Connection closed by 10.10.10.5
Nov  2 08:40:27 node1 sshd[4862]: Transferred: sent 30632, received 7024 bytes
Nov  2 08:40:27 node1 sshd[4862]: Closing connection to 10.10.10.5 port 50445
Nov  2 08:40:27 node1 sshd[4859]: pam_unix(sshd:session): session closed for user scott 

Le cose importanti da notare qui sono duplici

1. Vediamo l'impronta digitale della chiave pubblica utilizzata per autenticarmi
2. Vediamo il timestamp del mio log off

Utilizzando LogLevel (INFO) predefinito non registra nessuno di questi elementi. Ottenere l'impronta digitale di una chiave è un ulteriore passaggio. Devi elaborare il authorized_keysfile appropriato con ssh-keygen come tale.

[root@node1 ssh]# ssh-keygen -l -f /home/scott/.ssh/authorized_keys
4096 f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06 /home/scott/.ssh/authorized_keys (RSA)

Quindi ora conosci le seguenti informazioni:

1. Nome utente che ha effettuato l'accesso
2. Ora in cui l'utente ha effettuato l'accesso
3. Quale chiave pubblica è stata utilizzata per l'autenticazione
4. Tempo in cui l'utente si è disconnesso

Ora che abbiamo un modo per attribuire l'azione dell'utente in un momento specifico, supponendo che entrambi gli utenti non abbiano effettuato l'accesso contemporaneamente, possiamo iniziare a esaminare le modifiche apportate al repository.

Monitoraggio directory con Auditd

Come ha detto sysadmin1138, questo potrebbe essere un eccellente caso d'uso per il sottosistema auditd. Se non stai usando una distro basata su RedHat probabilmente c'è un analogo, ma dovrai trovarlo. La configurazione per auditd è piuttosto intensa e ha un numero ridondante di opzioni di configurazione. Per avere un'idea di alcune delle opzioni, consulta questa domanda sul nostro sito affiliato per i professionisti della sicurezza delle informazioni .

Come minimo, consiglierei di impostare quello che viene chiamato "watch" nella directory su disco che contiene il tuo repository git in questione. Quello che fa è istruire il modulo del kernel a riferire sui tentativi di eseguire chiamate di accesso ai file, come open()o creat(), su handle di file che puntano ai file o alle directory che elenchiamo.

Ecco un esempio di configurazione che farebbe questo e solo questo. Quindi fai attenzione a leggere e comprendere il tuo esistente /etc/audit/audit.rulesal fine di integrare le modifiche in modo appropriato.

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024

-w /path/to/git/repos-p wa

# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2

L'unico approccio tecnico che puoi adottare è fidarti dell'identità della connessione ssh. È quindi possibile imporre che ogni utente esegua il push dei commit effettuati solo convalidando il committer di ogni nuovo commit push.

Affinché ciò sia affidabile, quasi certamente non si vuole dare ai propri utenti un accesso shell senza restrizioni alla casella in cui risiede il repository; vorresti garantire l'uso di qualcosa come git-shellsolo altrimenti le restrizioni possono essere facilmente aggirate.

Gli utenti sarebbero comunque in grado di impersonarsi a vicenda come autori. Potresti anche limitare questo, ma questo perderebbe i flussi di lavoro comuni come la raccolta delle ciliegie e il rebasing e forse anche la ramificazione (a seconda dell'implementazione del hook), quindi potresti non voler fare questo.

Ad un certo punto, in una certa misura, devi fidarti dei tuoi sviluppatori.

Molti demoni ssh effettuano una registrazione /var/log/audit.logo qualcosa di simile quando si riceve una connessione ssh. Il riferimento incrociato a questo registro con il commit-log dovrebbe darti un'idea di quale utente ssh è stato usato per emettere un commit. Questa è una fase di controllo, da utilizzare dopo il fatto per la verifica.

Applicare effettivamente l'utente ssh corretto all'utente git appropriato è per una delle altre risposte qui.

Se tutti gli utenti dispongono di account di shell con accesso in scrittura al repository, non sarà possibile impostare un registro di controllo affidabile: potrebbero comunque modificare il repository senza scrivere nel registro e scrivere tutto ciò che desiderano nel registro.

Per poter fidare del registro di controllo, è necessario impedire l'accesso diretto in scrittura a livello di file al repository, invece di utilizzare qualcosa come gitolite (che viene eseguito nel proprio account) per mediare l'accesso al repository.