Ich habe einen Git-Server über ssh und jeder Benutzer hat ein Unix-Konto auf dem System.

Angesichts der Tatsache, dass zwei Benutzer Zugriff auf ein Repo haben, kann ich sicher sein, welcher Benutzer welches Commit ausgeführt hat, da der Commit-Benutzername und die E-Mail-Adresse vom Git-Client übermittelt und gesteuert werden.

Ich befürchte, dass ein Benutzer versuchen könnte, sich als ein anderer Benutzer auszugeben, selbst wenn er die gleichen Berechtigungsrechte besitzt.

Wenn Sie sich darüber Sorgen machen, gibt es verschiedene Möglichkeiten, das Problem zu lösen.

1. Lassen Sie Ihre Benutzer Ihre Commits signieren. GPG-Signaturen werden unterstützt.
2. Geben Sie den Benutzern nicht das Recht, ein Commit für das Haupt-Repository durchzuführen, sondern lassen Sie sie für ihr eigenes Unter-Repository ein Commit ausführen und lassen Sie die Änderungen dann von einem vertrauenswürdigen Benutzer in das Haupt-Repository übernehmen. Wenn Sie sich die Protokollnachrichten für einige Git-Projekte (z. B. Git selbst) ansehen, werden Sie feststellen, dass es separate Felder für "Autor" gibt - die Person, die die Änderung erstellt hat. und "Committer" - die Person, die die Änderung in das Repository übernommen hat.

Ich sehe zwei gute Möglichkeiten, diese Art von Informationen zu erhalten. Zum einen wird die Protokollierung von sshd selbst erhöht, zum anderen wird das Git-Repository auf der Festplatte genauer überwacht. Da keiner der beiden die gewünschten Informationen einzeln angibt, möchten Sie möglicherweise beides tun und die Protokolldaten mithilfe einer externen Protokollanalyse-Engine oder bei Bedarf mithilfe menschlicher Augen und Zeitstempel korrelieren.

sshd Modifikationen

Wie Sie zweifellos gesehen haben, können Sie standardmäßig mithilfe der ssh-Authentifizierungsprotokolle sehen, wann und von wo aus sich ein Benutzer angemeldet hat. Was Sie tun möchten, ist die Ebene zu ändern, auf der Sie sich von sshd abmelden. So bearbeiten Sie Ihre /etc/ssh/sshd_configund finden Sie die Linie, die aussieht

#LogLevel INFO

und ändern Sie das zu

LogLevel VERBOSE

Starten Sie dann den sshd-Dienst neu. Dies erhöht die Protokollierungsstufe von sshd um 1 Schritt, was viel mehr Informationen liefert. Schauen Sie sich diesen Protokollausschnitt meines Fernzugriffs an, nachdem Sie diese Änderung vorgenommen haben.

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 

Hier sind zwei wichtige Dinge zu beachten

1. Wir sehen den Fingerabdruck des öffentlichen Schlüssels, der zur Authentifizierung verwendet wird
2. Wir sehen den Zeitstempel meiner Abmeldung

Mit der Standardeinstellung LogLevel (INFO) protokolliert sshd keines dieser Elemente. Der Fingerabdruck eines Schlüssels ist ein zusätzlicher Schritt. Sie müssen die entsprechende authorized_keysDatei mit ssh-keygen als solche verarbeiten.

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

Nun kennen Sie also die folgenden Informationen:

1. Benutzername, der angemeldet ist
2. Uhrzeit, zu der sich der Benutzer angemeldet hat
3. Welcher öffentliche Schlüssel wurde für die Authentifizierung verwendet?
4. Uhrzeit, zu der sich der Benutzer abgemeldet hat

Da wir nun die Möglichkeit haben, Benutzeraktionen zu einem bestimmten Zeitpunkt zuzuweisen, sofern nicht beide Benutzer gleichzeitig angemeldet waren, können wir uns die Änderungen ansehen, die am Repository vorgenommen wurden.

Verzeichnisüberwachung mit Auditd

Wie sysadmin1138 sagte, könnte dies ein ausgezeichneter Anwendungsfall für das auditd-Subsystem sein. Wenn Sie keine RedHat-basierte Distribution verwenden, gibt es wahrscheinlich ein Analogon, aber Sie müssen es finden. Die Konfiguration für auditd ist ziemlich umfangreich und bietet eine Vielzahl von Konfigurationsoptionen. Sehen Sie sich diese Frage auf unserer Schwestersite für Informationssicherheitsspezialisten an, um sich einen Überblick über einige der Optionen zu verschaffen .

Auf jeden Fall würde ich empfehlen, in dem Verzeichnis auf der Festplatte, das das betreffende Git-Repository enthält, eine so genannte "Überwachung" einzurichten. Dadurch wird das Kernelmodul angewiesen, über Versuche zu berichten, Dateizugriffsaufrufe durchzuführen, wie z. B. open()oder creat()über Dateihandles, die auf die von uns aufgelisteten Dateien oder Verzeichnisse verweisen.

Hier ist eine Beispielkonfiguration, die dies und nur dies tun würde. Lesen und verstehen Sie daher Ihre vorhandenen Daten sorgfältig, um /etc/audit/audit.rulesÄnderungen angemessen zu integrieren.

# 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

Der einzige technische Ansatz, den Sie wählen können, besteht darin, der Identität der ssh-Verbindung zu vertrauen. Sie können dann erzwingen, dass jeder Benutzer nur die von ihm vorgenommenen Festschreibungen überträgt, indem Sie den Committer für jede neue übertragene Festschreibung validieren.

Damit dies zuverlässig ist, möchten Sie Ihren Benutzern mit ziemlicher Sicherheit keinen uneingeschränkten Shell-Zugriff auf die Box gewähren, in der sich das Repository befindet. Sie möchten die Verwendung von etwas sicherstellen, git-shellnur ansonsten werden die Einschränkungen leicht umgangen.

Benutzer können sich jedoch weiterhin als Autoren ausgeben. Sie könnten dies auch einschränken, dies würde jedoch die üblichen Arbeitsabläufe, wie z. B. das Ernten von Kirschen und das erneute Basieren und möglicherweise sogar das Verzweigen (abhängig von Ihrer Hook-Implementierung), verlieren, sodass Sie dies möglicherweise nicht möchten.

Zu einem gewissen Zeitpunkt müssen Sie Ihren Entwicklern vertrauen.

Viele ssh-Daemons machen einen Eintrag in /var/log/audit.logoder ähnliches, wenn eine ssh-Verbindung empfangen wird. Wenn Sie dieses Protokoll mit dem Festschreibungsprotokoll in Beziehung setzen, erhalten Sie eine Vorstellung davon, mit welchem ​​SSH-Benutzer eine Festschreibung durchgeführt wurde. Dies ist ein Überprüfungsschritt, der nachträglich zur Überprüfung verwendet wird.

Das Erzwingen des richtigen SSH-Benutzers gegenüber dem entsprechenden Git-Benutzer ist eine der anderen Antworten hier.

Wenn alle Benutzer über Shell-Konten mit Schreibzugriff auf das Repository verfügen, können Sie kein vertrauenswürdiges Überwachungsprotokoll einrichten: Sie können das Repository weiterhin ändern, ohne in das Protokoll zu schreiben, und sie können in das Protokoll schreiben, was sie möchten.

Um dem Überwachungsprotokoll vertrauen zu können, müssten Sie den direkten Schreibzugriff auf Dateiebene auf das Repository verhindern und stattdessen so etwas wie gitolite (das in einem eigenen Konto ausgeführt wird) verwenden, um den Zugriff auf das Repository zu vermitteln.