Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What I want to achieve is be able to record my terminal sessions to file automatically whenever I use Yakuake/Konsole.

It's easy to achieve if at the start of my session I do:

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

But I want to run the above automatically whenever I start Yakuake or open a new tab.

Using .bashrc does not work because it creates endless loop as 'script' opens a new session, which in turn reads .bashrc and starts another 'script' and so on.

So presumably I need to script Yakuake/Konsole somehow to run 'script' once as a new tab gets opened. The question is how?

share|improve this question
    
try the problematic solution with the loop problem, but prepend the exec at the start of the line. it should start the script -f in the same shell PID. – Hanan N. Nov 29 '11 at 22:28
    
Also interesting etended version of this quesion is how-to force as root the non-wheel users to script all their sessions as well ... – YordanGeorgiev May 28 '14 at 20:33

I figured it out myself :)

So if someone wants to record their terminal sessions automatically (including SSH sessions(!)) using script utility here is how:

Add the following line at the end of /etc/bash.bashrc file (or to .bashrc in your home if you only want your own sessions to be recorded):

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

(we test for shell's parent process not being script and then run script)

That's all! (assuming you have script installed, of course - script is part of bsdutils package) Now when you open new terminal you'll see:

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

script will write your sessions to a file in your home directory naming them something like *30-Nov-11_00-11-12_shell.log*. Adjust this part to suit yourself - for example, you can append your sessions to one large file rather than creating a new one for every session with script -a /path/to/single_log_file; or you can adjust where the files are written to - say, to /var/log/script/$USER_$(date +"%d-%b-%y_%H-%M-%S")_shell.log (make sure you've actually created /var/log/script and made it writable by others).

share|improve this answer
    
You can edit your question and its title yourself. Just click on the edit button that appears right below it. – Mat Nov 30 '11 at 6:51
5  
You might want to consider adding a ${RANDOM} and/or $$ to the file name since starting two shells within a second of each other will cause a file-name collision. Personally, i often use script.$(date -u +%Y%m%dt%H%M%S).${HOSTNAME:-$(hostname)}.$$.${RANDOM}.log to ensure the files are automatically sorted by date/time and they are consistent accross TZ, i know the host that initiated it, i know the owning process, and there are no name collisions. I rarely use ${USER} because it's typically something for only me. – nicerobot Dec 2 '11 at 16:33

Although this question was asked by an individual wanting to record his own sessions, an alternative use case might be a system administrator who wants to keep track of what various users are doing.

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.

This guide from 2008 uses a different method to force script to be run when a user logs in with ssh, which requires users to log in with a public/private key.

This is done by adding a script to the user's .ssh/authorized_keys file, in front of the key:

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

The log-session script then decides whether or not to run /usr/bin/script to log this user's session.

To prevent the user from removing the added command, the administrator will need to assume ownership of the user's authorized_keys file.

chown root:root ~user/.ssh/authorized_keys

Unfortunately, this means the user won't be able to add any additional keys him/herself, or more importantly revoke the existing key if it is compromised, which is far from ideal.

It is common for sshd's default configuration to allow users to perform SFTP over their ssh login. This offers a way for users to edit files without the changes being logged. If the administrator does not want users to be able to do that, then he should either enable some logging for SFTP, or disable the service. Although even then, users could still make unseen changes to files by running something like this in their terminal:

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

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.