私が達成したいのは、Yakuake / Konsoleを使用するたびに、ターミナルセッションを自動的にファイルに記録できるようにすることです。

セッションの開始時に次のことを行うと簡単に達成できます。

script -f /home/$USER/bin/shell_logs/$(date +"%d-%b-%y_%H-%M-%S")_shell.log

しかし、私は夜明けを開始するか、新しいタブを開くたびに上記を自動的に実行したいと思います。

.bashrcを使用すると、「スクリプト」が新しいセッションを開き、次に.bashrcを読み取り、別の「スクリプト」を開始するなど、無限ループを作成するため、機能しません。

そのため、新しいタブが開かれたときに「スクリプト」を1回実行するために、なんとかしてやくあけ/コンソールのスクリプトを作成する必要があります。問題はどうやって？

誰かがscriptユーティリティを使用して、SSHセッション（！）を含むターミナルセッションを自動的に記録したい場合は、次のようにします。

.bashrcホームディレクトリの最後に次の行を追加します。そうでない/etc/bash.bashrc場合は、すべてのユーザーのセッションのみを記録する場合に追加します。シェルの親プロセスが存在しないことをテストしてscriptから実行しscriptます。

Linuxの場合：

test "$(ps -ocommand= -p $PPID | awk '{print $1}')" == 'script' || (script -f $HOME/$(date +"%d-%b-%y_%H-%M-%S")_shell.log)

BSDおよびmacOSの場合、次のように変更script -fしscript -Fます。

test "$(ps -ocommand= -p $PPID | awk '{print $1}')" == 'script' || (script -F $HOME/$(date +"%d-%b-%y_%H-%M-%S")_shell.log)

それで全部です！

新しいターミナルを開くと、次のように表示されます。

Script started, file is /home/username/file_name.log

script30-Nov-11_00-11-12_shell.logその結果、セッションをホームディレクトリ内のファイルに書き込み、結果としてセッションに名前を付けます。

その他のカスタマイズ：

• セッションごとに新しいファイルを作成するのではなく、1つの大きなファイルにセッションを追加できます。 script -a /path/to/single_log_file
• script -f（Linux）またはscript -F（BSDおよびmacOS）の後にパスを変更することにより、ファイルの書き込み先を調整できます

scriptもちろん、この回答はインストール済みであることを前提としています。Debianベースのディストリビューションでscriptは、bsdutilsパッケージの一部です。

この質問は自分のセッションを記録したい個人によって尋ねられましたが、別のユースケースは、さまざまなユーザーが何をしているかを追跡したいシステム管理者かもしれません。

scriptシステム全体の内部での実行bashrcは、マシンのユーザーがセッションの記録を作成することに抵抗がある場合に適さない可能性があります。

シークレットのままにしたいユーザーは、sshdに別のシェルを開くように要求することでロギングをバイパスするzshか（例：）、ロードさbash --rcfile ___れないように実行/etc/bash.bashrcできます。

代替アプローチ

2008年のこのガイド（アーカイブ）では、ユーザーがsshでログインしたときに強制的に実行されるように別の方法を使用scriptします。この方法では、ユーザーは公開/秘密キーでログインする必要があります。

これは、ユーザーの.ssh/authorized_keysファイルのキーの前にスクリプトを追加することで実行されます。

command="/usr/local/sbin/log-session" ssh-dss AAAAB3NzaC1kc3MAAAEBAMKr1HxJz.....

log-session（アーカイブ）スクリプトが実行するか否かを判断し/usr/bin/script、このユーザのセッションをログに記録します。

exec script -a -f -q -c "$SSH_ORIGINAL_COMMAND" $LOGFILE

ユーザーが追加されたコマンドを削除できないようにするには、管理者がユーザーのauthorized_keysファイルの所有権を引き受ける必要があります。

chown root:root ~user/.ssh/authorized_keys

残念ながら、これはユーザーが自分で追加のキーを追加できないことを意味します。さらに重要なことに、侵害された場合は既存のキーを取り消すことができます。

注意事項

sshdのデフォルト設定では、ユーザーがsshログインでSFTPを実行できるようにするのが一般的です。これにより、ユーザーは変更をログに記録せずにファイルを編集できます。管理者がユーザーにそれを許可しない場合は、SFTPの一部のログを有効にするか、サービスを無効にする必要があります。それでも、ユーザーは端末で次のようなものを実行することにより、ファイルに目に見えない変更を加えることができます。

curl "http://users.own.server/server/new_data" > existing_file

すべてのファイル履歴を記録するコピーオンライトファイルシステムを使用することにより、そのような変更を監視できる場合があります。

ただし、同様のトリックを使用すると、ユーザーはコマンドをログに記録せずに実行できます。

curl "http://users.own.server/server/secret_commands_824" | sh

私はそれに対する簡単な解決策を知りません。可能性は次のとおりです。

• すべてのネットワークデータをログに記録します（後で解きます）。
• すべてのシステムコールを記録します。

auditdを使用すると、このようなことが可能になります。

とにかく...

ユーザーセッションのログが管理者に実際のセキュリティを提供することはほとんどありません。デフォルトでは、ユーザーは自分のファイルのみを操作でき、システムに損害を与えることはできません。悪意のあるユーザーが特権をエスカレートできた場合、ログを無効にしてログを削除できます（管理者がログを別のマシンに追加専用の方法で保存するように設定していない場合）。

ユーザーセッションを自動的にログに記録する管理者は、おそらくこれが行われていることをユーザーに通知する必要があります。一部の法域では、この形式のデータ収集がデータまたはプライバシー法に違反する場合があります。そして少なくとも、ユーザーに気づかせるのは敬意を払うでしょう。

管理者がsudoユーザーのセッションを記録することに関心を持つ可能性が高くなります。それはおそらく別の答え、または実際には別の質問に取り組むことができます。

の代わりに：

test "$(ps -ocommand= -p $PPID | awk '{print $1}')" == 'script' ||

私は使うだろう：

grep -qx "$PPID" <(pgrep -x "script") ||

この場合、二重引用符は必要ありませんが、とにかく標準的な方法として使用する傾向があります。サブストリングとのまれではあるが問題のある一致を回避するために、grepとpgrepの両方に「x」スイッチを使用することをお勧めします。