Je vois deux bonnes façons d'obtenir ce genre d'informations. L'une consiste à augmenter la journalisation de sshd lui-même, et l'autre à effectuer une surveillance plus approfondie du dépôt git sur le disque. Comme aucune des deux ne vous donne individuellement les informations que vous voulez, vous pouvez vouloir faire les deux et corréler les données de log en utilisant un moteur d'analyse de log externe ou à la demande en utilisant des yeux humains et des timestamps.

Modifications de sshd

Par défaut, comme vous l'avez sans doute vu, vous pouvez voir quand un utilisateur s'est connecté, et d'où, en utilisant les journaux d'authentification ssh. Ce que vous voulez faire, c'est changer le niveau auquel vous vous déconnectez de sshd. Donc, modifiez votre /etc/ssh/sshd_config et trouvez la ligne qui ressemble à

#LogLevel INFO

et changez-le en

LogLevel VERBOSE

puis redémarrez le service sshd. Cela augmente le niveau de journalisation de sshd d'un cran, ce qui donne beaucoup plus d'informations. Regardez cet extrait de journal de mon accès à distance après avoir effectué ce changement.

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 

Les éléments importants à noter ici sont au nombre de deux

1. Nous voyons l'empreinte de la clé publique utilisée pour m'authentifier.
2. Nous voyons l'horodatage de ma déconnexion.

En utilisant le LogLevel par défaut (INFO), sshd n'enregistre aucun de ces éléments. Obtenir l'empreinte digitale d'une clé est une étape supplémentaire. Vous devez traiter le fichier authorized_keys avec ssh-keygen comme tel.

[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)

Vous connaissez donc maintenant les informations suivantes :

1. Nom d'utilisateur qui s'est connecté
2. Heure à laquelle l'utilisateur s'est connecté
3. Quelle clé publique a été utilisée pour l'authentification
4. Heure à laquelle l'utilisateur s'est déconnecté

Maintenant que nous avons un moyen d'attribuer l'action de l'utilisateur à un moment précis, en supposant que les deux utilisateurs n'étaient pas connectés en même temps, nous pouvons commencer à examiner les modifications apportées au référentiel.

Surveillance des répertoires avec Auditd

Comme l'a dit sysadmin1138, cela pourrait être un excellent cas d'utilisation du sous-système auditd. Si vous n'utilisez pas une distribution basée sur RedHat, il existe probablement un équivalent, mais vous devrez le trouver. La configuration d'auditd est assez intense et comporte un nombre redoutable d'options de configuration. Pour vous faire une idée de certaines de ces options, veuillez consulter ce qui suit 問いかけ sur notre sœur Site pour les professionnels de la sécurité de l'information .

Au minimum, je recommanderais de mettre en place ce que l'on appelle un "watch" sur le répertoire sur le disque qui contient votre dépôt git en question. Cela permet de demander au module du noyau de signaler les tentatives d'appels d'accès aux fichiers, telles que open() ou creat() sur les poignées de fichiers pointant vers les fichiers ou les répertoires que nous listons.

Voici un exemple de configuration qui ferait cela, et seulement cela. Prenez soin de lire et de comprendre votre configuration existante. /etc/audit/audit.rules afin d'intégrer les changements de manière appropriée.

# 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

La seule approche technique que vous pouvez adopter est de faire confiance à l'identité de la connexion ssh. Vous pourriez alors faire en sorte que chaque utilisateur ne pousse que les commits qu'il a fait en validant le committer de chaque nouveau commits poussé.

Pour que cela soit fiable, vous ne voulez certainement pas donner à vos utilisateurs un accès illimité Shell à la boîte où réside le dépôt ; vous voudriez assurer l'utilisation de quelque chose comme git-shell mais sinon, les restrictions sont facilement contournables.

Cependant, les utilisateurs pourront toujours se faire passer pour des auteurs. Vous pourriez également restreindre cette possibilité, mais cela entraînerait la perte de flux de travail courants, tels que le cherry-picking, le rebasing et peut-être même le branching (en fonction de l'implémentation de votre hook).

À un moment donné, dans une certaine mesure, vous devez faire confiance à vos développeurs.

De nombreux démons ssh font une entrée dans le fichier /var/log/audit.log ou quelque chose de similaire lorsqu'une connexion ssh est reçue. Le croisement de ce journal avec le commit-log devrait vous donner une idée de l'utilisateur ssh qui a été utilisé pour émettre un commit. Il s'agit d'une étape d'audit, à utiliser après coup à des fins de vérification.

En fait, l'application de l'utilisateur ssh correct à l'utilisateur git approprié est pour l'une des autres réponses ici.

Si tous les utilisateurs ont des comptes Shell avec un accès en écriture au référentiel, vous ne pourrez pas mettre en place un journal d'audit digne de confiance : ils pourront toujours modifier le référentiel sans écrire dans le journal, et ils pourront écrire ce qu'ils veulent dans le journal.

Pour être en mesure de faire confiance au journal d'audit, vous devriez empêcher l'accès direct en écriture au niveau du fichier au référentiel, en utilisant quelque chose comme gitolite (qui s'exécute dans son propre compte) pour gérer l'accès au référentiel.