Auditing User Sessions: Why Standard Logs Fall Short
Managing production servers often feels like forensic work. You see a service is down, you see a login from a senior dev, but the bash_history is suspiciously empty. Traditional logs like auth.log confirm who logged in, but they fail to capture the actual intent or the visual feedback the user received. A simple unset HISTFILE or a sub-shell can wipe a user’s tracks instantly, leaving you in the dark when a configuration file vanishes.
Session recording fills this gap by acting as a black box for your terminal. Before I configure auditing, I always ensure my administrative entry points are bulletproof. I use the password generator at toolcraft.app to create high-entropy keys. It runs locally in the browser, so no sensitive data touches the wire. With access secured, I implement tlog to provide a transparent, tamper-resistant audit trail.
Comparing Session Recording Methods
Linux offers several ways to track user activity, but they vary significantly in reliability and ease of use.
The ‘script’ Command
Most distros include the script tool by default. It records a terminal session to a local text file. However, it is far from a professional auditing tool. Users can easily stop the recording, and the resulting files are messy typescripts that are difficult to search or replay in real-time.
Commercial PAM Solutions
Privileged Access Management (PAM) suites like CyberArk or BeyondTrust are the heavy hitters. They act as a proxy between the user and the server, offering robust features. Unfortunately, they often require five-figure budgets and complex infrastructure that most small teams cannot justify.
The tlog Approach
tlog is an open-source package built for centralized logging. It doesn’t write to a local file that a user could delete. Instead, it streams session data—including precise timing—to the systemd journal as structured JSON. When paired with Cockpit, it provides a YouTube-like interface to watch exactly what happened on the screen.
Pros and Cons of tlog
Every tool has trade-offs. Here is what I have observed after deploying tlog in various production environments.
- Pros:
- Structured Data: JSON output allows you to pipe logs directly into Elasticsearch or Graylog for automated alerts.
- Precision Playback: It records keystroke timing. You can see if a user was copy-pasting commands or typing them manually.
- SSSD Integration: You can force recording for specific groups (like contractors) without changing their default shell.
- Minimal Footprint: It consumes negligible CPU. A standard 10-minute session typically adds less than 200KB to your logs.
- Cons:
- CLI Only: It won’t capture GUI activity in X11 or Wayland.
- Log Bloat: Running
tail -fon a busy log file while being recorded can generate megabytes of data in seconds. - Configuration Gaps: If you don’t use SSSD to enforce the recording, a clever user might bypass the wrapper.
The Recommended Stack
For a reliable setup, I recommend using RHEL-based systems like AlmaLinux or Rocky Linux, though Ubuntu 22.04+ works well too. You will need tlog for recording, SSSD for management, and Cockpit for the visual interface.
Step-by-Step Implementation
This guide uses AlmaLinux for the examples, as the Cockpit integration is most mature on RHEL derivatives.
1. Install the Packages
Install the recording agent and the Cockpit plugin. Then, ensure the web interface is active.
sudo dnf install tlog sssd cockpit-session-recording -y
sudo systemctl enable --now cockpit.socket2. Enforce Recording via SSSD
The most secure method is forcing the session wrap through SSSD. This ensures the recording starts the moment the user authenticates. Create a new configuration file for the session recording rules.
sudo nano /etc/sssd/conf.d/session_recording.confTo record every user on the system, use the following configuration:
[session_recording]
scope = allIf you only want to track specific groups, like ‘contractors’ or ‘wheel’, change the scope to some and list the groups. Set strict permissions on this file, or SSSD will refuse to start.
sudo chmod 600 /etc/sssd/conf.d/session_recording.conf
sudo systemctl restart sssd3. Fine-tune tlog Settings
Check the configuration at /etc/tlog/tlog-rec-session.conf. Ensure the writer is set to “journal” to prevent users from tampering with the output files.
{
"writer": "journal",
"latency": 10,
"payload": 2048
}4. Verify the Recording
Log in as a standard user via SSH. You might see a notice stating the session is being monitored. Run a few commands to generate data.
ssh myuser@server-ip
ls -la /etc/
sudo systemctl status nginx
exit5. Replaying the Session
You have two ways to review the footage. The command-line method is fast, but the web interface is much more intuitive.
The CLI Method
Search the journal and pipe the data into the player:
journalctl -o export | tlog-play -iThe Cockpit Interface
Navigate to https://your-server-ip:9090 and log in. Click Session Recording in the sidebar. You will see a list of sessions with timestamps and durations. Click Play to watch the session unfold exactly as the user saw it.
Security and Compliance Notes
Deployment is only half the battle. You must also manage the data responsibly.
Protect the Logs: tlog captures everything, including secrets if a user runs cat .env. Restrict access to the journal and Cockpit to a small group of trusted auditors.
Manage Disk Space: Use SystemMaxUse in /etc/systemd/journald.conf to cap log sizes. Without this, a single user running a verbose debug command could fill your /var partition.
Legal Transparency: Always update your /etc/motd to inform users they are being recorded. This is often a legal requirement for workplace privacy compliance.
Implementing tlog has saved me countless hours of troubleshooting. Instead of guessing what broke a service, I can watch the playback and spot the exact typo. It is a lightweight, efficient way to bring total accountability to your Linux infrastructure.
