我有一个运行在ssh上的git服务器，每个用户在系统上都有一个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. 用户注销的时间

现在，我们有了一种在特定时间归因于用户操作的方法，假设两个用户均未同时登录，我们就可以开始查看对存储库所做的更改。

已审核的目录监视

就像sysadmin1138所说的，这对于审计的子系统来说可能是一个很好的用例。如果您不使用基于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连接的身份。然后，您可以通过验证每个新的推送提交的提交者，来强制每个用户仅推送他所做的提交。

为了使这一点可靠，您几乎肯定不希望为您的用户提供无限制的shell访问存储库所在的框的权限；您可能希望确保git-shell仅使用类似的方法，否则限制很容易解决。

但是，用户仍然可以互相模仿为作者。您也可以对此进行限制，但是这样会丢失常见的工作流程，例如摘樱桃和重新定基，甚至分支（取决于您的钩子实现），因此您可能不想这样做。

在某种程度上，您需要信任开发人员。

/var/log/audit.log当接收到ssh连接时，许多ssh守护程序会在其中进行输入或类似的操作。将此日志与commit-log交叉引用应使您了解使用了哪个ssh-user发出提交。这是审核步骤，将在事实验证之后使用。

实际上，将正确的ssh-user强制为适当的git-user是这里其他答案之一。

如果所有用户都具有具有对存储库的写访问权的Shell帐户，则您将无法建立可信赖的审核日志：他们仍然可以在不写入日志的情况下修改存储库，并且可以将所需的内容写入日志。

为了能够信任审核日志，您需要阻止对存储库的直接文件级写访问，而不是使用诸如gitolite（以其自己的帐户运行）之类的方式来调解对存储库的访问。