4 added 75 characters in body
source | link

This guide from 2008 (archived) 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.

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

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.

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

This guide from 2008 (archived) 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.

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

3 added 110 characters in body
source | link

An alternative approach

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

Caveats

ABut a similar trick would allow a user to execute commands without them being logged:

A similar trick would allow a user to execute commands without them being logged:

An alternative approach

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

Caveats

But a similar trick would allow a user to execute commands without them being logged:

2 added 456 characters in body
source | link

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.homeown.server/server/new_data" > existing_file

It might be possible to monitor changes like that by using a copy-on-write filesystem that records all file history.

A similar trick would allow a user to execute commands without them being logged:

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

I don't know of any easy solutions to that. Possibilities might be:

  • Logging all network data (and untangling it later).
  • Logging all system calls.

This sort of thing might be possible with auditd.

But anyway...

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.

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.

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.own.server/server/new_data" > existing_file

It might be possible to monitor changes like that by using a copy-on-write filesystem that records all file history.

A similar trick would allow a user to execute commands without them being logged:

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

I don't know of any easy solutions to that. Possibilities might be:

  • Logging all network data (and untangling it later).
  • Logging all system calls.

This sort of thing might be possible with auditd.

But anyway...

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.

1
source | link