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

Как минимум, я бы порекомендовал настроить то, что называется " 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 делают запись в /var/log/audit.log или в чем-то подобном при получении ssh-соединения. Перекрестные ссылки этого журнала с журналом фиксации должны дать вам представление о том, какой пользователь ssh использовался для выполнения фиксации. Это этап аудита, который будет использоваться для проверки постфактум.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.