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

Це легко досягти, якщо на початку моєї сесії я роблю:

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

Але я хочу запустити вищезазначене автоматично, коли я запускаю Yakuake або відкриваю нову вкладку.

Використання .bashrc не працює, оскільки він створює нескінченний цикл, оскільки "script" відкриває новий сеанс, який, в свою чергу, читає .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

Я не знаю жодного легкого рішення для цього. Можливості можуть бути:

• Реєстрація всіх мережевих даних (і розв’язування їх пізніше).
• Реєстрація всіх системних викликів.

Така річ може бути можливою з аудитом .

Але все ж таки...

Навряд чи реєстрація сеансів користувача забезпечує будь-яку реальну безпеку для адміністраторів. За замовчуванням користувач може маніпулювати лише власними файлами та не може завдати шкоди системі. Якщо зловмисному користувачеві вдалося збільшити привілеї, він міг відключити ведення журналу та видалити журнали (якщо адміністратор не налаштував журнали зберігатись на окремій машині, лише в додатку).

Адміністратори, які автоматично реєструють сеанси користувача, повинні, ймовірно, повідомляти користувачів, що це робиться . У деяких юрисдикціях ця форма збору даних може порушувати закони про дані чи конфіденційність . І принаймні, було б шанобливо, щоб користувачі донесли їх до відома.

Більш імовірно, що адміністратору буде цікаво реєструвати сеанси sudoкористувачів. Можливо, це можна вирішити в іншій відповіді, або в іншому питанні.

Замість:

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

Я б використав:

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

У цьому випадку подвійні лапки не потрібні, але я, як правило, використовую їх як стандартну практику. Я, безумовно, рекомендую використовувати перемикач "x" як на grep, так і на pgrep, щоб уникнути рідкісного, але проблемного збігу з підрядками.