То, чего я хочу достичь, - это возможность автоматически записывать сеансы терминала в файл всякий раз, когда я использую Yakuake / Konsole.

Это легко сделать, если в начале моей сессии я сделаю:

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

Но я хочу запускать вышеупомянутое автоматически всякий раз, когда я запускаю Yakuake или открываю новую вкладку.

Использование .bashrc не работает, потому что он создает бесконечный цикл, поскольку «скрипт» открывает новый сеанс, который, в свою очередь, читает .bashrc и запускает другой «скрипт» и так далее.

Так что, предположительно, мне нужно как-то написать скрипт Yakuake / Konsole, чтобы один раз запустить «скрипт» при открытии новой вкладки. Вопрос в том, как?

Если кто-то хочет записывать свои терминальные сеансы автоматически - включая сеансы SSH (!) - используя scriptутилиту, вот как.

Добавьте следующую строку в конец .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

scriptзапишет ваши сеансы в файл в вашем домашнем каталоге, назвав их 30-Nov-11_00-11-12_shell.logв результате.

Больше настроек:

• Вы можете добавлять свои сеансы в один большой файл, а не создавать новый для каждого сеанса с 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 года ( в архиве ) использует другой метод , чтобы силы scriptдля запуска , когда пользователь входит в систему с SSH, который требует , чтобы пользователи войти с / закрытым ключом общественности.

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

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

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

Но подобный трюк позволит пользователю выполнять команды без их регистрации:

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

Я не знаю каких-либо простых решений для этого. Возможности могут быть:

• Регистрация всех сетевых данных (и распутывание их позже).
• Регистрация всех системных вызовов.

Подобные вещи могут быть возможны с помощью audd .

Но все таки...

Маловероятно, что регистрация пользовательских сеансов обеспечивает какую-либо реальную безопасность для администраторов. По умолчанию пользователь может манипулировать только своими файлами и не может нанести вред системе. Если злоумышленнику удалось повысить привилегии, он мог бы отключить ведение журнала и удалить журналы (если администратор не настроил журналы для хранения на отдельном компьютере только в режиме добавления).

Администраторы, которые автоматически регистрируют сеансы пользователей, вероятно, должны информировать пользователей о том, что это делается . В некоторых юрисдикциях такая форма сбора данных может нарушать законы о данных или конфиденциальности . И, по крайней мере, было бы уважительно для пользователей, чтобы они знали.

Более вероятно, что администратор будет заинтересован в регистрации сеансов sudoпользователей. Возможно, это может быть решено в другом ответе или даже в другом вопросе.

Вместо того:

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

Я хотел бы использовать:

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

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