To, co chcę osiągnąć, to móc automatycznie rejestrować sesje terminali w plikach za każdym razem, gdy korzystam z Yakuake / Konsole.

Łatwo to osiągnąć, jeśli na początku mojej sesji:

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

Ale chcę uruchomić powyższe automatycznie przy każdym uruchomieniu Yakuake lub otwarciu nowej karty.

Korzystanie z .bashrc nie działa, ponieważ tworzy nieskończoną pętlę, ponieważ „skrypt” otwiera nową sesję, która z kolei odczytuje .bashrc i uruchamia kolejny „skrypt” i tak dalej.

Przypuszczalnie więc muszę jakoś napisać skrypt do Yakuake / Konsole, aby uruchomić skrypt „raz” po otwarciu nowej karty. Pytanie brzmi jak?

Jeśli ktoś chce automatycznie nagrywać sesje terminali - w tym sesje SSH (!) - za pomocą scriptnarzędzia, oto jak to zrobić.

Dodaj następujący wiersz na końcu .bashrcw swoim katalogu domowym lub w inny sposób, /etc/bash.bashrcjeśli chcesz nagrywać tylko sesje wszystkich użytkowników. Testujemy, czy proces macierzysty powłoki nie jest, scripta następnie uruchamiamy script.

W systemie Linux:

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

W przypadku BSD i macOS zmień script -fna script -F:

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

To wszystko!

Teraz, gdy otworzysz nowy terminal, zobaczysz:

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

scriptzapisze twoje sesje do pliku w twoim katalogu domowym, nazywając je 30-Nov-11_00-11-12_shell.logw rezultacie czymś takim .

Więcej personalizacji:

• Możesz dołączyć swoje sesje do jednego dużego pliku zamiast tworzyć nowy dla każdej sesji z script -a /path/to/single_log_file
• Możesz dostosować miejsce zapisu plików, zmieniając ścieżkę po script -f(Linux) lub script -F(BSD i macOS)

Ta odpowiedź zakłada scriptoczywiście , że zainstalowałeś. W przypadku dystrybucji opartych na Debianie scriptjest częścią bsdutilspakietu.

Chociaż pytanie to zostało zadane przez osobę chcącą nagrać własne sesje, alternatywnym przypadkiem użycia może być administrator systemu, który chce śledzić, co robią różni użytkownicy.

Obawiam się, że uruchamianie scriptw całym systemie bashrcmoże nie być odpowiednie w przypadku, gdy użytkownicy maszyny niechętnie nagrywają sesje.

Użytkownicy, którzy chcą pozostać incognito, mogą pominąć rejestrowanie, prosząc sshd o otwarcie innej powłoki (np. zsh) Lub uruchomienie, bash --rcfile ___aby zapobiec /etc/bash.bashrczaładowaniu.

Alternatywne podejście

W tym przewodniku z 2008 r. ( Zarchiwizowanym ) zastosowano inną metodę wymuszenia scripturuchomienia, gdy użytkownik loguje się przy użyciu ssh, co wymaga od użytkowników zalogowania się przy użyciu klucza publicznego / prywatnego.

Odbywa się to poprzez dodanie skryptu do .ssh/authorized_keyspliku użytkownika przed kluczem:

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

log-session( Archiwum ) skrypt następnie decyduje, czy nie uruchomić /usr/bin/scriptsię zalogować sesji tego użytkownika.

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

Aby uniemożliwić użytkownikowi usunięcie dodanego polecenia, administrator będzie musiał przejąć własność authorized_keyspliku użytkownika .

chown root:root ~user/.ssh/authorized_keys

Niestety oznacza to, że użytkownik nie będzie mógł dodawać żadnych dodatkowych kluczy ani, co ważniejsze, odwołać istniejącego klucza, jeśli zostanie naruszony, co jest dalekie od ideału.

Ostrzeżenia

Domyślną konfiguracją sshd jest to, że pozwala użytkownikom na wykonywanie SFTP podczas logowania ssh. Umożliwia to użytkownikom edycję plików bez rejestrowania zmian. Jeśli administrator nie chce, aby użytkownicy mogli to zrobić, powinien włączyć rejestrowanie SFTP lub wyłączyć usługę. Chociaż nawet wtedy użytkownicy nadal mogą dokonywać niewidocznych zmian w plikach, uruchamiając coś takiego w swoim terminalu:

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

Możliwe może być monitorowanie takich zmian za pomocą systemu plików kopiowania przy zapisie, który rejestruje całą historię plików.

Ale podobna sztuczka pozwoliłaby użytkownikowi na wykonywanie poleceń bez ich logowania:

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

Nie znam na to łatwych rozwiązań. Możliwościami mogą być:

• Rejestrowanie wszystkich danych sieciowych (i rozplątywanie ich później).
• Rejestrowanie wszystkich wywołań systemowych.

To może być możliwe w przypadku audytu .

Ale w każdym razie...

Jest mało prawdopodobne, aby rejestrowanie sesji użytkownika zapewniało jakiekolwiek rzeczywiste bezpieczeństwo dla administratorów. Domyślnie użytkownik może manipulować tylko własnymi plikami i nie może zaszkodzić systemowi. Jeśli złośliwemu użytkownikowi udało się eskalować uprawnienia, może wyłączyć rejestrowanie i usunąć dzienniki (chyba że administrator skonfigurował dzienniki do przechowywania na osobnym komputerze, w sposób dołączany tylko jako dodatek).

Administratorzy, którzy automatycznie rejestrują sesje użytkowników, powinni prawdopodobnie poinformować użytkowników, że jest to wykonywane . W niektórych jurysdykcjach ta forma gromadzenia danych może naruszać przepisy dotyczące danych lub prywatności . A przynajmniej uświadomienie ich użytkownikom byłoby z szacunkiem dla użytkowników.

Bardziej prawdopodobne jest, że administrator będzie zainteresowany rejestrowaniem sesji sudoużytkowników. Można temu zaradzić w innej odpowiedzi, a nawet w innym pytaniu.

Zamiast:

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

Użyłbym:

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

W tym przypadku podwójne cudzysłowy nie są konieczne, ale i tak używam ich jako standardowej praktyki. Zdecydowanie polecam użycie przełącznika „x” zarówno dla grep, jak i pgrep, aby uniknąć rzadkiego, ale problematycznego dopasowania do podciągów.