如果您担心这个问题，可以采取几种方法来解决这个问题。

1. 让你的用户签署你的提交，支持GPG签名。
2. 不要让用户有权提交到主存储库，让他们提交到他们自己的子库，然后让一个可信用户将这些更改带入主存储库。 这就是为什么如果你看一些git项目（比如git本身）的日志消息，你会发现它们是“Author”的独立字段 – 创build这个变化的人。 和“提交者” – 将更改提交到存储库的人员。

我看到了获取这种信息的两种好方法。 一个是通过增加sshd本身的日志logging，另一个是通过对磁盘上的git存储库进行更深入的监控。 由于没有一个人单独给你提供你想要的信息，你可能需要使用外部日志分析引擎或者使用人眼和时间戳进行关联。

sshd修改

默认情况下，您可以看到，当用户使用sshauthentication日志login时，可以看到用户从哪里login。 你想要做的就是在你注销sshd的时候改变级别。 所以编辑你的/etc/ssh/sshd_config并find如下所示的行

 #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. 我们看到用于validation我的公钥的指纹
2. 我们看到我注销的时间戳

使用默认的LogLevel（INFO）sshd不logging这些项目。 获取密钥的指纹是一个额外的步骤。 您必须使用ssh-keygen处理相应的authorized_keys文件。

 [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. login的用户名
2. 用户login的时间
3. 哪个公用密钥用于authentication
4. 用户注销的时间

现在我们有一种方法可以在特定时间对用户操作进行赋值，假设两个用户都没有同时login，我们可以开始查看对储存库所做的更改。

目录监视与审计

正如sysadmin1138所说的，这对auditd子系统来说可能是一个很好的用例。 如果你没有使用基于RedHat的发行版，可能有一个类似的，但你必须find它。 auditd的configuration非常紧张，并且有很多configuration选项。 要了解一些选项，请在我们的信息安全专业人员的姊妹网站上查看此问题 。

最起码，我build议在包含你的git仓库的磁盘目录上build立一个叫做“watch”的东西。 这是指示内核模块报告对文件句柄进行文件访问调用的尝试，如open()或creat() ，指向我们列出的文件或目录。

这是一个示例configuration，将这样做，只有这一点。 所以要小心阅读并理解你现有的/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连接的身份。 然后，您可以强制每个用户通过validation每个新推送落实的提交者来推送他所提交的提交。

为了这是可靠的，你几乎肯定不想让你的用户无限制地访问存储库所在的盒子; 你会想确保使用像git-shell这样的东西，否则这些限制很容易解决。

尽pipe如此，用户仍然可以模仿对方作为作者。 你也可以限制这个，但是这会失去一些常见的工作stream程，如樱桃采摘和重新绑定，甚至可能分支（取决于你的钩子实现），所以你可能不想这样做。

在某种程度上，你需要相信你的开发者。

许多ssh守护进程在/var/log/audit.log或类似的东西在ssh连接时收到一个条目。 交叉引用这个日志和提交日志应该给你一个关于哪个ssh用户被用来发出提交的想法。 这是一个审计步骤，在事后进行validation。

其实执行正确的SSH用户适当的GIT用户是在这里的其他答案之一。

如果所有用户都拥有可以对存储库进行写入访问的shell帐户，那么您将无法设置可信的审计日志：他们仍然可以在不写入日志的情况下修改存储库，并且可以将任何他们想要的内容写入日志。

为了能够信任审计日志，您需要防止对存储库的直接文件级写入访问，而不是使用像gitolite（在其自己的帐户中运行）来调解对存储库的访问。