Como gravar automaticamente todas as suas sessões de terminal com o utilitário de script

Question

O que eu quero alcançar é gravar minhas sessões de terminal para arquivar automaticamente sempre que eu usar o Yakuake / Konsole.

É fácil de conseguir se, no início da minha sessão, eu fizer isso:

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

Mas quero executar o acima automaticamente sempre que iniciar o Yakuake ou abrir uma nova guia.

O uso de .bashrc não funciona porque cria um ciclo infinito quando o 'script' abre uma nova sessão, que por sua vez lê o .bashrc e inicia outro 'script' e assim por diante.

Então, presumivelmente, preciso rotear o Yakuake / Konsole de alguma forma para executar o 'script' uma vez quando uma nova guia for aberta. A questão é como?

    

Answer 1

Se alguém quiser gravar suas sessões de terminal automaticamente (incluindo sessões SSH (!)) usando o utilitário 'script *, veja como.

Adicione a seguinte linha ao final de .bashrc em sua casa (ou /etc/bash.bashrc se você quiser apenas registrar as sessões de todos os usuários). Testamos o processo pai do shell não sendo script e, em seguida, executamos script .

para Linux:

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

para o BSD e o macOS, altere script -f para script -F :

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

Isso é tudo! (Presumindo que você tenha script instalado, é claro. Nas distribuições baseadas no Debian, script é parte do pacote bsdutils .)

Agora, quando você abrir um novo terminal, verá:

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

script escreverá suas sessões em um arquivo em seu diretório pessoal, nomeando-as como *30-Nov-11_00-11-12_shell.log* . Ajuste esta parte para se adequar. Por exemplo, você pode anexar suas sessões a um arquivo grande em vez de criar um novo para cada sessão com script -a /path/to/single_log_file . Você pode ajustar onde os arquivos são gravados alterando o caminho após script -f ( script -F no BSD / macOS).

    

Answer 2

Embora essa pergunta tenha sido feita por um indivíduo que deseja gravar suas próprias sessões, um caso de uso alternativo pode ser um administrador do sistema que deseja acompanhar o que vários usuários estão fazendo.

I fear running script inside the system-wide bashrc might not be suitable in the case when users of the machine are reluctant to have recordings made of their sessions.

Users who wish to remain incognito could bypass the logging by asking sshd to open a different shell (e.g. zsh) or run bash --rcfile ___ to prevent /etc/bash.bashrc from being loaded.

Uma abordagem alternativa

Este guia de 2008 ( arquivado ) usa um método diferente para forçar o script a ser executado quando um usuário efetua login com ssh, o que requer que os usuários efetuem login com uma chave pública / privada.

Isso é feito adicionando um script ao arquivo .ssh/authorized_keys do usuário, na frente da chave:

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

O log-session ( arquivado ) script decide se deve ou não executar /usr/bin/script para registrar a sessão deste usuário.

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

Para evitar que o usuário remova o comando adicionado, o administrador precisará assumir a propriedade do arquivo authorized_keys do usuário.

chown root:root ~user/.ssh/authorized_keys

Infelizmente, isso significa que o usuário não poderá adicionar nenhuma chave adicional ou, mais importante, revogar a chave existente se estiver comprometida, o que está longe de ser ideal.

Advertências

É comum que a configuração padrão do sshd permita que os usuários executem SFTP através de seu login ssh. Isso oferece uma maneira de os usuários editarem arquivos sem que as alterações sejam registradas. Se o administrador não quiser que os usuários façam isso, ele deverá habilitar algum log para SFTP ou desabilitar o serviço. Embora, mesmo assim, os usuários ainda possam fazer alterações invisíveis nos arquivos executando algo parecido com isso no terminal:

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

Pode ser possível monitorar mudanças como essa usando um sistema de arquivos copy-on-write que registra todo o histórico de arquivos.

Mas um truque semelhante permitiria que um usuário executasse comandos sem que eles fossem registrados:

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

Eu não conheço nenhuma solução fácil para isso. Possibilidades podem ser:

• Registrando todos os dados da rede (e desemaranhando-os depois).
• Registrando todas as chamadas do sistema.

Esse tipo de coisa pode ser possível com auditd .

Mas de qualquer forma ...

It is unlikely that logging user sessions provides any real security for administrators. By default a user can only manipulate their own files, and cannot harm the system. If a malicious user did manage to escalate privileges, then he could disable logging and delete the logs (unless the administrator has configured logs to be stored on a separate machine, in an append-only fashion).

Administrators who do automatically log user sessions should probably inform the users that this is being done. In some jurisdictions, this form of data collection might violate data or privacy laws. And at the very least, it would be respectful to users to make them aware.

It is more likely that an administrator would be interested in logging the sessions of sudo users. That could perhaps be tackled in a different answer, or indeed a different question.

    

Answer 3

Em vez de:

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

Eu usaria:

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

As aspas duplas não são necessárias neste caso, mas eu costumo usá-las de qualquer maneira como uma prática padrão. Eu definitivamente recomendo usar a opção "x" para o grep e o pgrep, para evitar uma correspondência rara, mas problemática, com substrings.