Right, so you’ve configured sudo to let your users do powerful things without handing out the actual root password. Smart move. But power without accountability is how you get a server that suddenly decides to host a crypto-mining operation for the “Minecraft Fan Club.” The entire point of sudo is delegated privilege, and the entire point of delegated privilege is knowing who did what and when. That’s where logging comes in, and it’s non-negotiable.

Forget the Hollywood trope of a hacker typing furiously with a “bypassing mainframe logs” pop-up. Good sudo logging creates an indelible, timestamped record. If something goes sideways, your first question shouldn’t be “what happened?” but “where are the logs?” For us on modern Linux systems, that means two primary destinations: the classic flat file (/var/log/auth.log or its cousins) and the all-encompassing binary juggernaut, journald.

The Trusty Text File: /var/log/secure and Friends

First, the old reliable. sudo talks to the system logger, syslog, which dutifully writes its entries to a file. On Ubuntu and Debian systems, you’ll find this in /var/log/auth.log. On Red Hat, Fedora, and CentOS, it’s /var/log/secure. They’re the same thing, just named differently to keep you on your toes.

Open one up. You’ll see lines that look like this:

Jun 12 10:23:45 my-server sudo: alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/apt update

Let’s autopsy this. It tells you the timestamp, the user (alice), the terminal she was on (pts/0), her current working directory, which user she became (root), and the exact command she ran. This is forensic gold. You can grep this file to see everything a user has done:

grep 'sudo:.*alice' /var/log/auth.log

Or find all commands that touched a specific sensitive directory:

grep 'PWD=/etc' /var/log/secure

The Pitfall: The main weakness of this text-based logging is log rotation. These files get compressed and kicked off to /var/log/auth.log.2.gz after a while. You absolutely must have a proper log aggregation system (like an ELK stack, Grafana Loki, or even just remote syslog) set up if you’re serious about security. Local logs can be altered or deleted by a privileged attacker covering their tracks.

The New School: systemd-journald

On systems running systemd (which is pretty much all of them now), there’s a second, parallel logging system: the journal. The journal is a binary file that stores not just logs, but metadata, making it far more powerful for querying. You interact with it using the journalctl command.

The beauty of the journal is its rich querying syntax. Since it knows sudo is a system unit, you can ask it very specific questions. To see all sudo entries from the last hour:

journalctl -u sudo.service --since "1 hour ago"

Even better, you can query by a specific user or process. This command shows you every command alice ran with sudo:

journalctl _COMM=sudo USER=alice

Why is this better than grepping a text file? Speed and context. The journal indexes these fields, so querying is instantaneous even across gigantic logs. It can also show you the boot context and other process metadata that syslog ignores.

The Rough Edge: The journal’s primary weakness is that its binary logs are typically stored in /var/log/journal and, unless you’ve configured it otherwise, have a size limit and will eventually prune old data. For a true audit trail, you must configure journald for persistent storage and increase its size, or, more sensibly, forward its messages to a remote server. Relying solely on the local journal is a recipe for losing critical evidence.

Best Practice: Log Everything. No, Seriously.

The default sudo logging is good, but you can make it viciously detailed. The log_input and log_output directives in your sudoers file are a game-changer for true auditing. log_input logs every keystroke, and log_output logs every byte of output, of the sudo-spawned session. It’s incredibly verbose and a privacy concern for users, so deploy it judiciously—perhaps only for specific, highly sensitive commands or users.

# In /etc/sudoers.d/audit
Defaults log_input, log_output

This will create a replayable transcript of the entire session in /var/log/sudo-io. It’s the closest you can get to a surveillance camera inside your terminal. It’s overkill for apt update, but if someone is going to sudo su - or edit your pg_hba.conf file, you’ll be thankful for the verbosity.

The bottom line is this: configuring sudo is only half the job. If you aren’t actively watching, securing, and archiving the logs it generates, you might as well not bother. The log is the contract. Make sure it’s unbreakable.