タイトルの通りです。

記録されるのはログインユーザ

Linux ディストリビューションに最初から入っている OpenSSH は、初期設定で /var/log/secure や /var/log/auth.log に情報を書きます。実際に書いているのはなんらかの Syslog 実装です。

普通に ssh や sftp でログインすると、アクセス元 IP アドレスとユーザ名が記録されることはお馴染みです。

Apr 21 21:32:21 www4146ue sshd[21991]: Accepted publickey for ogata from 192.168.0.100 port 61024 ssh2
Apr 21 21:32:21 www4146ue sshd[21991]: pam_unix(sshd:session): session opened for user ogata by (uid=0)
Apr 21 21:32:22 www4146ue sshd[21996]: subsystem request for sftp by user ogata

多くの場合これで用が足りるのですが、事情があって共有アカウントとして運用されているユーザの場合、実際にどの人間がログインを行ったのかは分かりません。

個別にアカウントがある踏み台サーバを用意すれば、そこから共有アカウントでログインした記録を追うことも頑張れば出来そうですが、同時刻にログイン操作をする人が複数名いたりするだけで相当面倒そうです。

最近ではパスワードログインはできないようにして、各操作者から公開鍵をもらった公開鍵ログインが主流になってきました。どの公開鍵でログインが行われたか（認証と許可が行われたか）が分かれば、共有アカウントでもうまくいくかもしれません。

どの公開鍵で認証したか記録する方法

どの公開鍵で認証したかの記録ですが、sshd(8) にはこれに応えるオプションがあります。LogLevel という項目です。

LogLevel
  Gives the verbosity level that is used when logging messages from sshd(8).
  The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1,
  DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent.
  DEBUG2 and DEBUG3 each specify higher levels of debugging output.
  Logging with a DEBUG level violates the privacy of users and
  is not recommended.

（man 5 sshd_config より）

デフォルトは INFO で、普通はこれを変更することはありませんが、一段情報量の多い VERBOSE にすると、以下のログが記録されます。

Mar 30 14:42:10 www4146ue sshd[8457]: Found matching RSA key: 91:98:00:92:dc:43:8e:ff:35:f4:9c:d7:5f:1f:c2:a4

これは、PID 8457 の sshd プロセスにて、このフィンガープリントを持った公開鍵が認証でマッチしたということです。

authorized_keys には1行1公開鍵という形式で記録されていますが、各公開鍵がどのようなフィンガープリントを持つかというのは、以下のようなコマンドで分かります。

{ cat .ssh/authorized_keys ; echo "" ; } | \
    while read line ; do \
        echo $line ; \
        echo $line > /tmp/pubkey ; \
        ssh-keygen -l -E md5 -f /tmp/pubkey ; \
        echo "" ; \
    done

雑に書いたので、取得した一行が公開鍵であるかないかといった判定は省いてあります。

改ざんやシステムトラブルに備えるには

システムの堅牢性やユーザの善良さなどに対して疑うのであれば、ディスクなどのシステム全体が突然故障して復旧不可能になってしまうことや、悪意を持ったユーザによってログを改ざんされないかといったこと（やむを得ず特権ユーザを共有アカウントとして使う場合）へも配慮する必要があるかもしれません。

厳格な対応をするのであれば SELinux といった大仰な対策となるのでしょうが、簡単に対処するのであれば sshd がログ記録を依頼する Syslog の記録先をアクセス可能なユーザを限定したリモートサーバにしてしまうのがいいかもしれません。

多くの初期設定の元で sshd はｓyslog ファシリティ AUTH でログを記録します。AUTH 全体をリモートサーバの syslog で受けたり、別のファシリティを /etc/ssh/sshd_config の SyslogFacility 設定オプションで設定して、それだけをリモートサーバで受けたりといった方法が考えられます。

共用アカウントについて

共用アカウントは一般的によくないものとされていて、本来であれば操作者に対応したユーザを各サーバに作成して、特権アクセスが必要な場合には都度 sudo などを使うのが理想的と言われています。私が最初に勤めていた会社ではこの方針が厳格に貫かれていましたが、10人程度の操作者と100台弱のサーバだけでも入社退職に関わるユーザ管理が大変でした。規模や操作者の出入りの頻度によってはもっとシステマティックなものを導入する必要があるでしょう。

共用アカウントと sudo でバッチリと言われることもあるのですが、sudo で許可するコマンドは限界まで減らさないと、悪意のある操作者の悪事を防止することはできません。chmod や chown さえできてしまえば、どんなコマンドも特権ユーザの権限がなくても実行できる抜け道となってしまいます。mv ができれば、特権実行可能なコマンドを悪意のある実行ファイルで置き換えることで何でもできてしまいます。

セキュリティまわりは考え始めるとキリがないので、IT業界で長く働いて感じることは、プロジェクトメンバー間の信頼関係が何より大事だということです。