У меня есть git-сервер, работающий через ssh, и у каждого пользователя есть учетная запись unix в системе.

Учитывая, что два пользователя имеют доступ к репо, как я могу быть уверен, какой пользователь выполнил какую-либо фиксацию, поскольку имя пользователя и электронная почта для фиксации передаются и контролируются клиентом git.

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

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

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, это может быть отличным вариантом использования для подсистемы audd. Если вы не используете дистрибутив на основе RedHat, возможно, есть аналог, но вам придется его найти. Конфигурация для audd довольно интенсивна и содержит много вариантов конфигурации. Чтобы получить представление о некоторых из вариантов, пожалуйста, проверьте этот вопрос на нашем родственном сайте для специалистов по информационной безопасности .

Как минимум, я бы порекомендовал установить так называемый «watch» для каталога на диске, который содержит ваш 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 (который запускается под собственной учетной записью) для обеспечения доступа к хранилищу.