Quello che voglio ottenere è poter registrare le mie sessioni del terminale su file automaticamente ogni volta che uso Yakuake / Konsole.

È facile da ottenere se all'inizio della mia sessione faccio:

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

Ma voglio eseguire automaticamente quanto sopra ogni volta che avvio Yakuake o apro una nuova scheda.

L'uso di .bashrc non funziona perché crea un ciclo infinito poiché "script" apre una nuova sessione, che a sua volta legge .bashrc e avvia un altro "script" e così via.

Quindi presumibilmente ho bisogno di scrivere Yakuake / Konsole in qualche modo per eseguire 'script' una volta che viene aperta una nuova scheda. La domanda è: come?

Se qualcuno vuole registrare automaticamente le proprie sessioni terminali - comprese le sessioni SSH (!) - usando l' scriptutilità, ecco come.

Aggiungi la seguente riga alla fine di .bashrcnella tua home directory, o altrimenti /etc/bash.bashrcse vuoi solo registrare tutte le sessioni degli utenti. Testiamo che il processo padre della shell non sia scripte quindi eseguiamo script.

Per Linux:

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

Per BSD e macOS, passare script -fa script -F:

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

È tutto!

Ora quando apri un nuovo terminale vedrai:

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

scriptscriverà le tue sessioni su un file nella tua home directory nominandole come qualcosa come 30-Nov-11_00-11-12_shell.logrisultato.

Più personalizzazione:

• Puoi aggiungere le tue sessioni a un file di grandi dimensioni anziché crearne uno nuovo per ogni sessione con script -a /path/to/single_log_file
• È possibile regolare la posizione in cui vengono scritti i file modificando il percorso dopo script -f(Linux) o script -F(BSD e macOS)

Questa risposta presuppone che tu abbia scriptinstallato, ovviamente. Sulle distribuzioni basate su Debian, scriptfa parte del bsdutilspacchetto.

Sebbene questa domanda sia stata posta da una persona che desidera registrare le proprie sessioni, un caso d'uso alternativo potrebbe essere un amministratore di sistema che desidera tenere traccia di ciò che stanno facendo i vari utenti.

Temo che correre scriptall'interno del sistema bashrcpotrebbe non essere adatto nel caso in cui gli utenti della macchina siano riluttanti a fare registrazioni delle loro sessioni.

Gli utenti che desiderano rimanere in incognito potrebbero ignorare la registrazione chiedendo a sshd di aprire una shell diversa (ad es. zsh) O eseguire bash --rcfile ___per impedire il /etc/bash.bashrccaricamento.

Un approccio alternativo

Questa guida del 2008 ( archiviata ) utilizza un metodo diverso per forzare scriptl'esecuzione quando un utente accede con ssh, il che richiede agli utenti di accedere con una chiave pubblica / privata.

Questo viene fatto aggiungendo uno script al .ssh/authorized_keysfile dell'utente , davanti alla chiave:

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

Lo script log-session( archiviato ) decide quindi se eseguire o meno /usr/bin/scriptper registrare la sessione di questo utente.

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

Per impedire all'utente di rimuovere il comando aggiunto, l'amministratore dovrà assumere la proprietà del authorized_keysfile dell'utente .

chown root:root ~user/.ssh/authorized_keys

Sfortunatamente, ciò significa che l'utente non sarà in grado di aggiungere altre chiavi se stesso o, soprattutto, di revocare la chiave esistente se è compromessa, il che è tutt'altro che ideale.

Avvertenze

È comune per la configurazione predefinita di sshd consentire agli utenti di eseguire SFTP sul proprio login ssh. Ciò offre agli utenti un modo per modificare i file senza che le modifiche vengano registrate. Se l'amministratore non desidera che gli utenti siano in grado di farlo, dovrebbe abilitare un po 'di registrazione per SFTP o disabilitare il servizio. Anche se anche allora, gli utenti potrebbero ancora apportare modifiche invisibili ai file eseguendo qualcosa di simile nel loro terminale:

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

Potrebbe essere possibile monitorare tali cambiamenti utilizzando un filesystem copy-on-write che registra tutta la cronologia dei file.

Ma un trucco simile consentirebbe a un utente di eseguire comandi senza che vengano registrati:

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

Non conosco soluzioni facili a questo. Le possibilità potrebbero essere:

• Registrare tutti i dati di rete (e districarli in seguito).
• Registrazione di tutte le chiamate di sistema.

Questo genere di cose potrebbe essere possibile con auditd .

Ma in ogni caso...

È improbabile che la registrazione delle sessioni utente offra una sicurezza reale agli amministratori. Per impostazione predefinita, un utente può solo manipolare i propri file e non può danneggiare il sistema. Se un utente malintenzionato è riuscito a intensificare i privilegi, potrebbe disabilitare la registrazione ed eliminare i registri (a meno che l'amministratore non abbia configurato i registri per essere archiviati su un computer separato, in modo solo accodamento).

Gli amministratori che registrano automaticamente le sessioni degli utenti dovrebbero probabilmente informare gli utenti che ciò è stato fatto . In alcune giurisdizioni, questa forma di raccolta dei dati potrebbe violare le leggi sulla privacy o dei dati . E per lo meno, sarebbe rispettoso per gli utenti renderli consapevoli.

È più probabile che un amministratore sia interessato a registrare le sessioni degli sudoutenti. Ciò potrebbe forse essere affrontato in una risposta diversa, o in effetti in una domanda diversa.

Invece di:

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

Io userei:

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

Le doppie virgolette non sono necessarie in questo caso, ma tendo ad usarle comunque come pratica standard. Consiglio vivamente di usare l'opzione "x" sia su grep che su pgrep, per evitare una corrispondenza rara ma problematica con sottostringhe.