ssh pass original user to environment on server

Question

First off, i do not know wether passing the information to the environment is the best approach, so i will start by detailing what i actually want to achieve.

on a corporate scale, there are servers where a number of employees have individual shell accounts, they are using these accounts to connect to other servers, using public-key authentication, logging in as root.

what i want to do, is be able, to tell, on the remote servers they are logging into, what the user account on the server they are coming from was.

for example user John Doe, has an account on central.server, he logs into his account jdoe, the jdoe user now connects to remote.server.1 and logs in as root with public-key auth.

I want to log the commands he is issuing on remote.server.1, but i want to retain the information that he is actually jdoe on central.server

So, basically i want to be able to pull a log from remote.server.1 and see which employee did what, when and where

I understand that i could just add some logging into the profile or bashrc on remote.server.1 and have sshd set up with PermitUserEnvironment, use a global profile on central.server and use that to pass the username in an environment variable to remote.server.1

I wonder if there is a better way to achieve that?

Thanks

Answer 1

There is no way to both retain auditing capabilities and letting users become root.

Instead, grant sudo access to the commands your users need, and log everything.

From the sudoers(5) man page:

 sudoers also supports logging a command's input and output streams.  I/O logging is not on by default but can be enabled using the log_input and log_output Defaults flags as well as the LOG_INPUT and LOG_OUTPUT command tags.

 log_input         If set, sudo will run the command in a pseudo tty and log all user input.  If the standard input is not connected to the user's tty, due to I/O redirection or because the command is part of a pipeline, that input is also captured and
                   stored in a separate log file.  This flag is off by default.

                   Input is logged to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that is included in the normal sudo log line, prefixed with “TSID=”.  The iolog_file option may be used to con‐
                   trol the format of the session ID.

                   Note that user input may contain sensitive information such as passwords (even if they are not echoed to the screen), which will be stored in the log file unencrypted.  In most cases, logging the command output via log_output is all
                   that is required.

 log_output        If set, sudo will run the command in a pseudo tty and log all output that is sent to the screen, similar to the script(1) command.  If the standard output or standard error is not connected to the user's tty, due to I/O redirection or
                   because the command is part of a pipeline, that output is also captured and stored in separate log files.  This flag is off by default.

                   Output is logged to the directory specified by the iolog_dir option (/var/log/sudo-io by default) using a unique session ID that is included in the normal sudo log line, prefixed with “TSID=”.  The iolog_file option may be used to con‐
                   trol the format of the session ID.

                   Output logs may be viewed with the sudoreplay(8) utility, which can also be used to list or search the available logs.

Additionally, you want to log sudo usage as well:

 sudoers can log both successful and unsuccessful attempts (as well as errors) to syslog(3), a log file, or both.  By default, sudoers will log via syslog(3) but this is changeable via the syslog and logfile Defaults settings.

As a final note, you'll need to ensure that the access granted to your users does not grant too broad permissions, so as to allow them overriding the audit system.

Answer 2

The first and best solution is to simply not allow SSH logins to the root account. As you've found for yourself, this makes it very hard to track who did what. People who should have access to a server should use their own accounts, and then use sudo to perform tasks requiring root access. This is the current best practice for SSH access.

You might also want to setup audit logging on the central server from which the users do their SSH work. You can use auditctl to log ssh commands only. (Turning audit on will slow the server down to some extent, though; you'd need to do some performance evaluations to determine if it works for you.)

You could also add information to the public part of the SSH key on the target servers - see this question for some tips on that. However, since the users have root, it will be easy for them to alter this data, so it's not usable for any serious auditing.

Also, if you set LogLevel to VERBOSE, sshd will log the fingerprint of the ssh key used to login. But unless those logs are forwarded to a remote server, to which these people do not have access, they may get tampered with and thus do not constitute a reliable audit trail.