sshで実行されているgitサーバーがあり、各ユーザーはシステム上にUNIXアカウントを持っています。

2人のユーザーがリポジトリにアクセスできる場合、コミットユーザー名と電子メールはgitクライアントによって送信および制御されるため、どのユーザーがどのコミットを実行したかをどのようにして確認できますか。

ユーザーが同じ承認権限を持っている場合でも、ユーザーが別のユーザーになりすまそうとするのではないかと心配しています。

あなたがそれを心配しているなら、問題に対処するいくつかの方法があります。

1. ユーザーにコミットに署名させ、GPG署名のサポートがあります。
2. ユーザーにメインリポジトリにコミットする権利を与えないで、自分のサブリポジトリにコミットしてから、信頼できるユーザーに変更をメインリポジトリに持ってきてもらいます。そのため、一部のgitプロジェクト（git自体など）のログメッセージを見ると、それらが「作成者」（変更を作成した人）の個別のフィールドであることがわかります。「コミッター」-変更をリポジトリーにコミットした人。

この種の情報を取得するには、2つの良い方法があります。1つはsshd自体からのロギングを増やすことによるもので、もう1つはディスク上の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 

ここで注意すべき重要な点は2つあります

1. 私の認証に使用された公開鍵の指紋が表示されます
2. ログオフのタイムスタンプが表示されます

デフォルトのLogLevel（INFO）sshdを使用すると、これらの項目は記録されません。キーのフィンガープリントを取得することは、1つの追加ステップです。authorized_keysssh-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の構成は非常に強力であり、構成オプションの数が膨大です。いくつかのオプションのアイデアを得るには、情報セキュリティ専門家の姉妹サイトでこの質問をチェックしてください。

最低限、問題の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接続のアイデンティティを信頼することです。次に、プッシュされた各コミットのコミッターを検証することにより、各ユーザーがコミットしたもののみをプッシュするように強制できます。

これを信頼できるものにするためには、リポジトリが存在するボックスへの無制限のシェルアクセスをユーザーに与えたくないでしょう。git-shellそうでない場合にのみ制限を簡単に回避できるようなものの使用を保証したいと思うでしょう。

ただし、ユーザーはお互いを作成者として偽装することができます。これも制限できますが、チェリーピッキングやリベースなどの一般的なワークフローが失われる可能性があり、フックの実装に応じて分岐することもあるため、これを行いたくない場合があります。

ある時点で、ある程度までは、開発者を信頼する必要があります。

多くのsshデーモン/var/log/audit.logは、ssh接続を受信すると、エントリまたはそれに類似したものを作成します。このログをcommit-logと相互参照すると、コミットを発行するためにどのssh-userが使用されたかがわかります。これは、検証の事実の後に使用される監査ステップです。

実際に適切なgit-userに正しいssh-userを強制することは、ここでの他の答えの1つです。

すべてのユーザーがリポジトリへの書き込みアクセス権を持つシェルアカウントを持っている場合、信頼できる監査ログを設定することはできません。ユーザーは、ログに書き込むことなくリポジトリを変更でき、ログに必要なものを書き込むことができます。

監査ログを信頼できるようにするには、リポジトリへの直接のファイルレベルの書き込みアクセスを防止し、代わりにgitolite（独自のアカウントで実行）などを使用してリポジトリへのアクセスを仲介する必要があります。