I see two good ways of getting this kind of information. One is by increasing the logging from sshd itself, and the other by doing deeper monitoring of the git repository on disk. Since neither one individually gives you the information you want, you may want to do both and correlate the log data using an external log analysis engine or on demand using human eyes and timestamps.
sshd Modifications
By default, as you've no doubt seen, you can see when a user logged in, and from where, using the ssh authentication logs. What you want to do is change the level at with you're logging out of sshd. So edit your /etc/ssh/sshd_config
and find the line that looks like
#LogLevel INFO
and change that to
LogLevel VERBOSE
then restart the sshd service. This increases the logging level of sshd by 1 step, which gives a lot more information. Check out this log snippet of my remote access after making that change.
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
The important things to notice in here are two-fold
- We see the fingerprint of the public key used to authenticate me
- We see the timestamp of my log off
Using the default LogLevel (INFO) sshd logs neither of those items. Getting the fingerprint of a key is one extra step. You have to process the appropriate authorized_keys
file with ssh-keygen as such.
[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)
So now you know the following pieces of information:
- Username that logged on
- Time that user logged on
- Which public key was used for authentication
- Time that user logged off
Now that we have a way to attribute user action at a specific time, assuming both users weren't logged in at the same time, we can start looking at the changes made to the repository.
Directory Monitoring with Auditd
As sysadmin1138 said, this could be an excellent use case for the auditd subsystem. If you are not using a RedHat based distro there is probably an analogue, but you'll have to find it. The configuration for auditd is pretty intense and has a redonkulous number of configuration options. To get an idea of some of the options, please check out this question on our sister site for Information Security Professionals.
Minimally, I would recommend setting up what's called a "watch" on the directory on disk that contains your git repository in question. What this does is instruct the kernel module to report on attempts to perform file access calls, such as open()
or creat()
, on file handles pointing to the files or directories we list.
Here's a sample config that would do this, and only this. So be careful to read through, and understand, your existing /etc/audit/audit.rules
in order to integrate changes appropriately.
# 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