Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

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 is the preferred method to keep track of who is acting as root in the logs when root login is disabled (SSH) but users can run sudo -i or su - to become root? I would like to follow every command with the original username as well. RHEL 6 or any Linux rsyslog, etc.

share|improve this question

On Red Hat distros you typically use the /var/log/secure log to identify who's been logging in or making use of sudo on a Fedora/CentOS/RHEL system.


sudo example
$ sudo -Es

log result:

Sep 1 19:32:51 greeneggs sudo: saml : TTY=pts/2 ; PWD=/home/saml ; USER=root ; COMMAND=/bin/bash

su example
$ su -

log result:

Sep 1 19:34:49 greeneggs su: pam_unix(su-l:session): session opened for user root by saml(uid=1000)

share|improve this answer

If you have cooperating users, you can setup rootsh to log everything the root user types to syslog.


rootsh rpms are available in EPEL.

The version of sudo on RHEL6 is also capable of logging stdout to a file for every sudo session. Look into the sudo_plugins man page.

Neither of these approaches is completely bulletproof.

share|improve this answer

The most robust methods seems to be auditd:


Auditd basically intercepts all system calls and checks them against your set of rules. So in your /etc/audit/audit.rules file you would have something like the following:

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 320

# Feel free to add below this line. See auditctl man page
-a always,exit -F euid=0 -F perm=wxa -k ROOT_ACTION

The last rule being the only non-default rule.

The main drawback with this approach (and the reason I found this question while looking for alternatives) is that the raw log files are pretty cryptic and are only helpful after running the querying program on the raw log file: ausearch

An example query for that rule would be:

ausearch -ts today -k ROOT_ACTION -f audit_me | aureport -i -f

A common sense solution would probably be to create a cron that will query your raw auditd logs and then ship them off to your logging solution.

share|improve this answer

Your Answer


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.