Хотя этот вопрос был задан человеком, желающим записывать свои собственные сессии, альтернативным вариантом может быть использование системным администратором, который хочет отслеживать, что делают различные пользователи.

Боюсь, что запуск script внутри общесистемного bashrc может не подойти в случае, когда пользователи машины не хотят, чтобы записи их сессий велись.

Пользователи, желающие остаться инкогнито, могут обойти протоколирование, попросив sshd открыть другую оболочку (например, zsh) или выполнить bash --rcfile ___, чтобы предотвратить загрузку /etc/bash.bashrc.

Альтернативный подход

Это руководство от 2008 года (архивировано) использует другой метод, чтобы заставить скрипт запускаться, когда пользователь входит в систему с помощью ssh, который требует от пользователей входа с открытым/закрытым ключом.

Это делается путем добавления скрипта в файл .ssh/authorized_keys пользователя, перед ключом:

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

Скрипт log-session (archived) затем решает, запускать или нет /usr/bin/script для регистрации сессии этого пользователя.

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

Чтобы пользователь не смог удалить добавленную команду, администратор должен будет принять право собственности на файл authorized_keys пользователя.

chown root:root ~user/.ssh/authorized_keys

К сожалению, это означает, что пользователь не сможет самостоятельно добавить дополнительные ключи или, что более важно, отозвать существующий ключ, если он скомпрометирован, что далеко не идеально.

Предостережения

Обычно стандартная конфигурация sshd позволяет пользователям выполнять SFTP через их логин ssh. Это дает пользователям возможность редактировать файлы без записи изменений в журнал. Если администратор не хочет, чтобы пользователи могли это делать, то он должен либо включить протоколирование для 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") ||

Двойные кавычки в этом случае не нужны, но я все равно использую их как стандартную практику. Я определенно рекомендую использовать переключатель «x» как для grep, так и для pgrep, чтобы избежать редких, но проблемных совпадений с подстроками.