Lo que quiero lograr es poder grabar mis sesiones de terminal para archivarlas automáticamente cada vez que use Yakuake / Konsole.

Es fácil de lograr si al comienzo de mi sesión hago:

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

Pero quiero ejecutar lo anterior automáticamente cada vez que inicio Yakuake o abra una nueva pestaña.

El uso de .bashrc no funciona porque crea un bucle sin fin ya que 'script' abre una nueva sesión, que a su vez lee .bashrc e inicia otro 'script' y así sucesivamente.

Por lo tanto, presumiblemente necesito guiar a Yakuake / Konsole de alguna manera para ejecutar 'script' una vez que se abre una nueva pestaña. La pregunta es cómo.

Si alguien quiere grabar sus sesiones de terminal automáticamente, incluidas las sesiones SSH (!), Utilizando la scriptutilidad, aquí le mostramos cómo.

Agregue la siguiente línea al final de .bashrcsu directorio de inicio, o de lo contrario /etc/bash.bashrcsi solo desea grabar todas las sesiones de los usuarios. Probamos que el proceso padre de shell no esté scripty luego lo ejecutamos 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 BSD y macOS, cambie 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)

¡Eso es todo!

Ahora, cuando abra una nueva terminal, verá:

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

scriptescribirá sus sesiones en un archivo en su directorio de inicio nombrándolos como algo como 30-Nov-11_00-11-12_shell.logresultado.

Más personalización:

• Puede agregar sus sesiones a un archivo grande en lugar de crear uno nuevo para cada sesión con script -a /path/to/single_log_file
• Puede ajustar dónde se escriben los archivos cambiando la ruta después de script -f(Linux) o script -F(BSD y macOS)

Esta respuesta asume que has scriptinstalado, por supuesto. En distribuciones basadas en Debian, scriptes parte del bsdutilspaquete.

Aunque esta pregunta fue formulada por un individuo que deseaba grabar sus propias sesiones, un caso de uso alternativo podría ser un administrador del sistema que quisiera hacer un seguimiento de lo que están haciendo varios usuarios.

Me temo que correr scriptdentro del sistema bashrcpodría no ser adecuado en el caso de que los usuarios de la máquina sean reacios a hacer grabaciones de sus sesiones.

Los usuarios que deseen permanecer de incógnito pueden omitir el registro al pedirle a sshd que abra un shell diferente (por ejemplo zsh) o que se ejecute bash --rcfile ___para evitar que /etc/bash.bashrcse cargue.

Un enfoque alternativo

Esta guía de 2008 ( archivada ) utiliza un método diferente para forzar la scriptejecución cuando un usuario inicia sesión con ssh, lo que requiere que los usuarios inicien sesión con una clave pública / privada.

Esto se hace agregando un script al .ssh/authorized_keysarchivo del usuario , delante de la clave:

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

El script log-session( archivado ) decide si se ejecuta o no /usr/bin/scriptpara registrar la sesión de este usuario.

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

Para evitar que el usuario elimine el comando agregado, el administrador deberá asumir la propiedad del authorized_keysarchivo del usuario .

chown root:root ~user/.ssh/authorized_keys

Desafortunadamente, esto significa que el usuario no podrá agregar ninguna clave adicional por sí mismo o, lo que es más importante, revocar la clave existente si está comprometida, lo que dista mucho de ser ideal.

Advertencias

Es común que la configuración predeterminada de sshd permita a los usuarios realizar SFTP a través de su inicio de sesión ssh. Esto ofrece a los usuarios una forma de editar archivos sin que se registren los cambios. Si el administrador no quiere que los usuarios puedan hacer eso, entonces debe habilitar algún registro para SFTP o deshabilitar el servicio. Aunque incluso entonces, los usuarios aún podrían hacer cambios invisibles en los archivos ejecutando algo como esto en su terminal:

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

Es posible monitorear cambios como ese mediante el uso de un sistema de archivos de copia en escritura que registra todo el historial de archivos.

Pero un truco similar permitiría a un usuario ejecutar comandos sin que se registren:

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

No conozco ninguna solución fácil para eso. Las posibilidades pueden ser:

• Registro de todos los datos de la red (y desenredarlos más tarde).
• Registro de todas las llamadas del sistema.

Este tipo de cosas podría ser posible con auditado .

Pero de todos modos...

Es poco probable que el registro de sesiones de usuario proporcione seguridad real para los administradores. Por defecto, un usuario solo puede manipular sus propios archivos y no puede dañar el sistema. Si un usuario malintencionado logró escalar privilegios, podría deshabilitar el registro y eliminar los registros (a menos que el administrador haya configurado los registros para que se almacenen en una máquina separada, solo para agregar).

Los administradores que registran automáticamente las sesiones de los usuarios probablemente deberían informar a los usuarios que esto se está haciendo . En algunas jurisdicciones, esta forma de recopilación de datos puede violar las leyes de datos o privacidad . Y, al menos, sería respetuoso con los usuarios informarles.

Es más probable que un administrador esté interesado en registrar las sesiones de los sudousuarios. Tal vez podría abordarse en una respuesta diferente, o incluso en una pregunta diferente.

En lugar de:

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

Yo usaría:

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

Las comillas dobles no son necesarias en este caso, pero tiendo a usarlas de todos modos como una práctica estándar. Definitivamente recomiendo usar el interruptor "x" para grep y pgrep, para evitar una coincidencia rara pero problemática con subcadenas.