Tengo un servidor git corriendo sobre ssh y cada usuario tiene una cuenta unix en el sistema.

Dado que dos usuarios tienen acceso a un repositorio, ¿cómo puedo estar seguro de qué usuario realizó cada confirmación, ya que el nombre de usuario y el correo electrónico de confirmación son enviados y controlados por el cliente git?

Me preocupa que un usuario pueda intentar hacerse pasar por otro, incluso si tienen los mismos derechos de autorización.

Si le preocupa tanto, hay un par de formas de abordar el problema.

1. Haga que sus usuarios firmen sus confirmaciones, hay soporte para la firma GPG.
2. No otorgue a los usuarios el derecho de comprometerse con el repositorio principal, pídales que se comprometan con su propio repositorio y luego haga que un usuario de confianza traiga los cambios al repositorio principal. Es por eso que si observa los mensajes de registro para algunos proyectos de git (como el propio git) verá que hay campos separados para "Autor", la persona que creó el cambio. y "Comprador": la persona que cometió el cambio en el repositorio.

Veo dos buenas formas de obtener este tipo de información. Una es aumentar el registro desde sshd, y la otra haciendo un monitoreo más profundo del repositorio git en el disco. Dado que ninguno de los dos le brinda la información que desea individualmente, es posible que desee hacer ambas cosas y correlacionar los datos de registro utilizando un motor de análisis de registro externo o bajo demanda utilizando ojos humanos y marcas de tiempo.

Modificaciones sshd

De manera predeterminada, como sin duda ha visto, puede ver cuándo un usuario inició sesión y desde dónde, utilizando los registros de autenticación ssh. Lo que quiere hacer es cambiar el nivel en el que está cerrando sesión en sshd. Edite su /etc/ssh/sshd_configy encuentre la línea que se parece a

#LogLevel INFO

y cambiar eso a

LogLevel VERBOSE

luego reinicie el servicio sshd. Esto aumenta el nivel de registro de sshd en 1 paso, lo que proporciona mucha más información. Echa un vistazo a este fragmento de registro de mi acceso remoto después de hacer ese cambio.

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 

Las cosas importantes a tener en cuenta aquí son dobles

1. Vemos la huella digital de la clave pública utilizada para autenticarme
2. Vemos la marca de tiempo de mi cierre de sesión

Al usar el nivel de registro predeterminado (INFO), sshd no registra ninguno de esos elementos. Obtener la huella digital de una clave es un paso adicional. Debe procesar el authorized_keysarchivo apropiado con ssh-keygen como tal.

[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)

Entonces ahora conoce la siguiente información:

1. Nombre de usuario que inició sesión
2. Hora en que el usuario inició sesión
3. Qué clave pública se usó para la autenticación
4. Hora en que el usuario cerró sesión

Ahora que tenemos una manera de atribuir la acción del usuario en un momento específico, suponiendo que ambos usuarios no hayan iniciado sesión al mismo tiempo, podemos comenzar a mirar los cambios realizados en el repositorio.

Monitoreo de directorios con Auditd

Como dijo sysadmin1138, este podría ser un excelente caso de uso para el subsistema auditado. Si no está utilizando una distribución basada en RedHat, probablemente haya un análogo, pero tendrá que encontrarlo. La configuración para auditado es bastante intensa y tiene una cantidad redonculosa de opciones de configuración. Para tener una idea de algunas de las opciones, consulte esta pregunta en nuestro sitio asociado para profesionales de seguridad de la información .

Como mínimo, recomendaría configurar lo que se llama un "reloj" en el directorio del disco que contiene su repositorio git en cuestión. Lo que esto hace es indicar al módulo del núcleo que informe sobre los intentos de realizar llamadas de acceso a archivos, como open()o creat(), en los identificadores de archivos que apuntan a los archivos o directorios que enumeramos.

Aquí hay una configuración de muestra que haría esto, y solo esto. Por lo tanto, tenga cuidado de leer y comprender su existencia /etc/audit/audit.rulespara integrar los cambios adecuadamente.

# 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

El único enfoque técnico que puede tomar es confiar en la identidad de la conexión ssh. Luego, podría exigir que cada usuario solo envíe confirmaciones que realizó al validar el confirmador de cada nueva confirmación enviada.

Para que esto sea confiable, es casi seguro que no desea dar a sus usuarios acceso ilimitado a la caja donde reside el repositorio; querrá garantizar el uso de algo como, de lo git-shellcontrario, las restricciones se solucionan fácilmente.

Sin embargo, los usuarios aún podrían hacerse pasar por autores. También podría restringir esto, pero esto perdería los flujos de trabajo comunes, como la selección de cerezas y el rebase y quizás incluso la ramificación (dependiendo de su implementación de enlace), por lo que es posible que no desee hacer esto.

En algún momento, hasta cierto punto, debe confiar en sus desarrolladores.

Muchos demonios ssh hacen una entrada /var/log/audit.logo algo similar cuando se recibe una conexión ssh. Hacer referencias cruzadas de este registro con el registro de confirmación debería darle una idea de qué usuario ssh se utilizó para emitir una confirmación. Este es un paso de auditoría, que se utilizará después del hecho para la verificación.

En realidad, imponer al usuario ssh correcto al usuario git apropiado es una de las otras respuestas aquí.

Si todos los usuarios tienen cuentas de shell con acceso de escritura al repositorio, no podrá configurar un registro de auditoría confiable: aún podrían modificar el repositorio sin escribir en el registro, y podrían escribir lo que quieran en el registro.

Para poder confiar en el registro de auditoría, debe evitar el acceso directo de escritura a nivel de archivo al repositorio, en lugar de usar algo como gitolite (que se ejecuta en su propia cuenta) para mediar el acceso al repositorio.