2人のユーザー間に共有SSHキー/(ユーザー名とパスワード)があるとし、それらをBobとAliceと呼びます。
Bobはサーバーに接続し、いくつかのコマンドチェーンを実行して、そのホストのいくつかの重要なデータを削除しました。
さらに、Alice は同じ共有資格情報を使用して同じホストに接続し、いくつかの更新を実行します。
sshd認証ログ(/var/log/auth.log)があり、イベント中に両方のユーザーが接続されていることを知っていますが、どのユーザー(ユーザーのIPが含まれているため接続されている)がそのイベントに責任があるかを区別する方法ありますか?イベントアクションチェーン?
答え1
これが、多くの企業が人間アカウントのSSHキーの使用を禁止するポリシーを持っている理由です。 SSHキーを共有したりパスワードを設定したりしないため、キー自体が本質的にファイルのパスワードになる傾向があります。
賢明な企業はセキュリティ製品を使用して、SSHキーを使用できるユーザー、そのキーを使用できる場所、接続の開始と終了が許可される場所を制御します。
安全ではなく感謝できないことが知られている行動を許可し、事後にこれを捉えようとします。最良の答えは、行動を完全に停止することです。
SSHキーの使用を制御するのに役立つ同じセキュリティ製品を、SSHセッションのキーストロークロギングにも使用できます。これにより、一意のログイベントをキャプチャし、接続のソースと宛先を表示し、ユーザーが入力したすべての見苦しいキーストロークを結果出力とともに表示できます。もちろん、これは商業的な解決策ですが、あなたのニーズに間違いなく合致します。
1つの可能なアプローチは、アカウントにログインするたびに一意のシェル履歴ファイルを使用することです。デフォルトでは、user.bashrc(またはそれに対応するエントリ)に次のようにHISTFILEを定義します。
TIMEST=`date +%Y.%m.%d-%H%M%S`
SOURCETERM=` who am i | awk '{print $5}'`
HISTFILE=.sh_history-$TIMEST"_"$SOURCETERM
これにより、セッションごとに次の名前の一意のシェル履歴ファイルが作成されます。
$HOME/.sh_history-2021.09.16-022345_(1.2.3.4)
これはあなたのニーズに適していますが、ユーザーが賢明な場合は、簡単にファイルを変更または削除したり、他の履歴ファイルを割り当てることができます。
あなたはほとんど不可能な問題を解決しようとしています。システムの観点から見ると、同じユーザーが2回ログインしています。コマンド、プロセス、メモリなどはUIDが所有し、同じ有効なUIDを持つ他の人が操作できます。
もう一度申し上げますが、正しい解決策はまず不安定な行動を防ぐことです。