Если вас это так беспокоит, есть несколько способов решить эту проблему.

1. Заставьте пользователей подписывать ваши коммиты, есть поддержка подписи GPG.
2. Не давайте пользователям право фиксировать изменения в основном репозитории, заставляйте их фиксировать изменения в своем собственном субрепозитории, а затем пусть доверенный пользователь внесет изменения в основной репозиторий. Вот почему, если вы посмотрите сообщения журнала для некоторых проектов git (например, самого git), вы увидите, что это отдельные поля для «Автор» - человека, создавшего изменение. и «Коммиттер» - человек, который внес изменение в репозиторий.

Я вижу два хороших способа получить такую ​​информацию. Один заключается в увеличении количества журналов из самого sshd, а другой - путем более глубокого мониторинга репозитория git на диске. Поскольку ни один из них по отдельности не предоставляет вам нужную информацию, вы можете сделать и то, и другое и сопоставить данные журнала с помощью внешнего механизма анализа журналов или по запросу с использованием человеческих глаз и временных меток.

sshd Модификации

По умолчанию, как вы, несомненно, видели, вы можете видеть, когда пользователь вошел в систему и откуда, используя журналы аутентификации ssh. Что вы хотите сделать, так это изменить уровень, на котором вы выходите из sshd. Так что отредактируйте свой /etc/ssh/sshd_config и найдите строку, которая выглядит как

#LogLevel INFO

и измените это на

LogLevel VERBOSE

затем перезапустите службу sshd. Это увеличивает уровень ведения журнала sshd на 1 шаг, что дает намного больше информации. Просмотрите этот фрагмент журнала моего удаленного доступа после внесения этого изменения.

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 

Здесь важно отметить два важных момента.

1. Мы видим отпечаток открытого ключа, который используется для аутентификации меня.
2. Мы видим отметку времени моего выхода из системы

При использовании стандартного уровня LogLevel (INFO) sshd не регистрирует ни один из этих элементов. Получение отпечатка пальца ключа - еще один дополнительный шаг. Вы должны обработать соответствующие authorized_keys файл с ssh-keygen как таковой.

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

Итак, теперь вы знаете следующую информацию:

1. Имя пользователя, которое вошло в систему
2. Время, когда пользователь вошел в систему
3. Какой открытый ключ использовался для аутентификации
4. Время, когда пользователь вышел из системы

Теперь, когда у нас есть способ приписать действие пользователя в определенное время, предполагая, что оба пользователя не вошли в систему одновременно, мы можем начать просматривать изменения, внесенные в репозиторий.

Мониторинг каталогов с помощью Auditd

Как сказал sysadmin1138, это может быть отличным вариантом использования подсистемы auditd. Если вы не используете дистрибутив на основе RedHat, вероятно, есть аналог, но вам придется его найти. Конфигурация для auditd довольно сложна и имеет огромное количество параметров конфигурации. Чтобы получить представление о некоторых вариантах, ознакомьтесь с этим вопрос на нашу сестру сайт для специалистов по информационной безопасности.

Как минимум, я бы рекомендовал установить так называемые «часы» в каталоге на диске, который содержит рассматриваемый репозиторий git. Это дает команду модулю ядра сообщать о попытках выполнить вызовы доступа к файлам, например open() или creat(), на дескрипторах файлов, указывающих на файлы или каталоги, которые мы перечисляем.

Вот пример конфигурации, которая будет делать это, и только это. Так что будьте осторожны, чтобы прочитать и понять существующую /etc/audit/audit.rules для надлежащей интеграции изменений.

# 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

Единственный технический подход, который вы можете использовать, - это доверять идентификатору ssh-соединения. Затем вы можете обеспечить, чтобы каждый пользователь отправлял только те коммиты, которые он сделал, проверяя коммиттера каждой новой отправленной фиксации.

Чтобы это было надежно, вы почти наверняка не хотите предоставлять своим пользователям неограниченный доступ к оболочке к ящику, в котором находится репозиторий; вы хотите использовать что-то вроде git-shell только в противном случае ограничения легко обойти.

Тем не менее, пользователи по-прежнему смогут выдавать себя за авторов. Вы также можете ограничить это, но это приведет к потере общих рабочих процессов, таких как выбор вишни и перебазирование и, возможно, даже ветвление (в зависимости от реализации вашего крючка), поэтому вы можете не захотеть этого делать.

В какой-то момент вам нужно в какой-то степени доверять своим разработчикам.

Многие демоны ssh делают запись в /var/log/audit.log или что-то подобное при получении ssh-соединения. Перекрестные ссылки этого журнала с журналом фиксации должны дать вам представление о том, какой пользователь ssh использовался для выполнения фиксации. Это этап аудита, который будет использоваться для проверки постфактум.

На самом деле принудительное применение правильного ssh-пользователя к соответствующему git-пользователю относится к одному из других ответов здесь.

Если у всех пользователей есть учетные записи оболочки с доступом на запись в репозиторий, вы не сможете настроить надежный журнал аудита: они все равно могут изменять репозиторий, не записывая в журнал, и они могут записывать в журнал все, что захотят.

Чтобы иметь возможность доверять журналу аудита, вам нужно запретить прямой доступ на запись на уровне файлов в репозиторий, вместо этого используя что-то вроде gitolite (который работает под собственной учетной записью) для посредничества при доступе к репозиторию.