Linux User Audit: Complete Guide in 5 Steps 2026

Please read this one carefully. This is the kind of thing that burned me twice in the last twelve months, and both times it was 100% preventable. The pattern is always the same: there’s an account on the server that should have lost access a long time ago, but it’s still there, still logging in, still poking around. And when you finally notice, you have zero trail to explain to management what happened. It’s like realizing you’ve been robbed, only to find out the security camera was never on.

This time around, the account belonged to a guy named Nguyen Hai Long. His contract ended two months ago, but his login was still alive on the production box. I’m not blaming him — I’m blaming us for not having a proper offboarding process. I learned that lesson the hard way, so I’m writing this so you don’t have to. Trust me, audit now or cry later. And no, this isn’t theory — it’s straight from tickets that actually landed on my desk.

Here’s the thing though: this isn’t really about one account. It’s about a pattern. If one stale login can slip through, imagine ten former employees whose accounts are still sitting there. The impact on a production server is obvious — data breach risk, unauthorized file changes, and the worst one of all, you playing guessing games over who changed a config at 3 AM. Management does not enjoy hearing “I don’t know who did it, boss.” And honestly, in the hosting world, this happens way more often than people admit. Plenty of small providers have no idea that old accounts still have full access to other clients’ servers.

And what makes it worse? The accounts that look “harmless” are often the ones with the widest access. It’s like leaving your back door unlocked and then wondering why stuff keeps going missing.

Before we start, let’s get one thing straight: auditing has to be a habit, not a reaction. In a production environment, every change should be traceable back to who made it. This isn’t paranoia, it’s accountability. Linux logs already store all of it — successful logins, sudo commands, even touched files — but most of us never bother to open them. So here’s a plan of 5 steps that use nothing but built-in commands. No extra tools, no agents, no SaaS signup. I’ve run these exact steps on Ubuntu, Debian, and CentOS, so a distro change won’t throw you off.

Why Auditing User Activity on a Linux Server Matters

Let me explain why this step gets skipped so often. Most admins think, “I only have two users, nobody’s going to do anything dumb.” That’s exactly the mindset that creates incidents. The Nguyen Hai Long case is a perfect example: it’s not that he was malicious, it’s that a dead account stayed alive — still able to log in, still able to reach sensitive data. A single login from an account that should be dead is enough to mess up a production config.

An audit is actually simple. You want to know three things: who can access the server, who has accessed it, and what they did. Answer those three with real log data and you’ll sleep a whole lot better. Think of it like house security: you should know who holds a key, when they came in, and what they walked out with. And as a bonus, a clean audit trail lets you prove to clients or management that everything is under control.

Auditing also makes your life easier the moment something breaks. The server throws an error, you need to know who touched the config last — you don’t have to ask around. You open the log and there’s your answer. Simple, but almost nobody does it consistently. If you spend a lot of time managing client servers, building this habit will save you a ton of grief when a client calls about a sudden slowdown or a weird file appearing in their web root.

5 Steps to Audit User Activity on a Linux Server

Okay, here’s the meat. These five steps go from the quick and easy to the deeper stuff. Everything uses tools that ship with the OS. And please — save the output somewhere. You’ll want it for your report. We’ll start with the list that changes the least, then move into the livelier logs.

Step 1: List Every User on the Server

First, let’s see who actually has an account. /etc/passwd holds the full list, but not every entry is a “real” user — a lot of them are system accounts. What you care about are users with UID 1000 and up.

cat /etc/passwd

awk -F: '$3 >= 1000 {print $1, $6}' /etc/passwd

You’re looking for output roughly like this (identities are masked):

root /root
nguyenhalong /home/nguyenhalong
dewirahayu /home/dewirahayu
admin-backup /home/admin-backup
www-data /var/www
sshd /run/sshd

This is where anomalies jump out. Say there’s an admin-backup account nobody remembers creating — that’s your lead. Don’t delete anything yet, just note it. We’ll handle cleanup at the end. The home directory column matters too, because it’s a hint about where that user’s files and history live. On a shared host, users with UID 1000+ are usually manually created, while cPanel accounts follow their own pattern.

The awk one-liner filters users with UID 1000 and above, a quick way to separate human accounts from system accounts. It’s not 100% accurate — system users can live above 1000 — but on a typical VPS or shared host, it catches the right ones 99% of the time. If the output is long, save it as a baseline: awk -F: ‘$3 >= 1000 {print $1, $6}’ /etc/passwd > /tmp/user-list.txt.

Step 2: Check Who Logged In, and When

Now for the interesting part: login history. /var/log/wtmp and /var/log/btmp hold that data, and you read them with the last command.

last -a

This shows every successful login with the source IP and timestamp. Example:

nguyenhalong pts/1 203.0.113.10 Sat Jul 18 22:14 still logged in
dewirahayu pts/0 198.51.100.5 Sat Jul 18 20:02 - 22:10 (02:08)
root pts/0 192.0.2.50 Sat Jul 18 09:31 - 10:45 (01:14)

For failed login attempts, use lastb. It needs root since it reads /var/log/btmp:

lastb | head -30

This is the moment that shocked me in the Nguyen Hai Long case. One look at last and I found his account had been logging in throughout the previous week — after his contract was over. Our offboarding was that broken. You should also watch the IP column. A login from an unusual IP, or from a country that makes no sense for your team, is a lead worth chasing.

To see who’s online right now, use who or w:

who
w

w is the more useful one — it also shows the command each user is running. That’s gold when you suspect someone is poking around live. Sessions that linger forever without activity are also worth a second look; they might be forgotten open connections.

Step 3: Dig Through Sudo and Privilege Activity

Logins alone don’t tell the whole story. Most of the damage on a server happens through sudo, and the good news is all of it is logged. On Debian/Ubuntu it lands in /var/log/auth.log; on CentOS/RHEL it’s /var/log/secure.

grep sudo /var/log/auth.log | tail -30

journalctl -u sudo --since "2026-07-01"

Sample output:

Jul 18 22:20:01 web-prod-1 sudo: nguyenhalong : TTY=pts/1 ; PWD=/home/nguyenhalong ; USER=root ; COMMAND=/bin/chown -R www-data:www-data /var/www/html

Read that line carefully: user nguyenhalong ran a chown with root privileges. If that user shouldn’t have elevated access anymore, that’s a red flag. Save suspicious lines to a file for documentation:

journalctl -u sudo --since "2026-01-01" > /tmp/audit-sudo.log

That’s for your records — nothing sketchy. And remember, raw logs contain sensitive info like IPs and usernames, so don’t post them publicly. If you want to show a client, sanitize first. More admins than you’d think forget this tiny step, then get surprised when the data leaks.

Step 4: Inspect SSH Keys and Open Doors

This is the step everyone skips, and it’s the most dangerous one. A single stale key in authorized_keys is a permanent backdoor into your server, even after you rotate every password. Check every user’s .ssh folder:

ls -la /home/*/.ssh/
cat /home/*/.ssh/authorized_keys

Look closely. Any key you don’t recognize, or one that belongs to a former employee, is a warning sign. A key you should be suspicious of looks like this:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBq...D/8zcVc2pZ7 user@laptop-lama

If you’re unsure about a key, copy it out first and check who added it before revoking. And don’t forget root’s authorized_keys — plenty of admins get burned by a root key with a murky history. We cover the full workflow in our guide on reading and managing SSH keys.

Step 5: Track File and Config Changes

This last step answers “who changed what, and when.” The simplest starting point: list files modified within a window.

find /etc -type f -newermt "2026-07-01" -not -path "*/cache/*" 2>/dev/null | head -30

That returns every config file touched since July 1. If you see a file you don’t remember editing, investigate. For details on a specific file, use stat:

stat /etc/ssh/sshd_config

For continuous, heavier monitoring you can set up auditd, but that deserves its own article. If you want to harden the server first, start with our guide on securing SSH against brute force.

Quick Reference: Which Log Tells You What

What to Do Once You Find Something

This is where people get trigger-happy. Found a suspicious account? They want to delete it right away. Stop. Don’t. The sequence below is mandatory if you don’t want to create a brand new incident while fixing an old one. Remember: the goal isn’t just cutting access, it’s preserving evidence and making sure you’re hitting the right target.

First, document everything. Save the output from all five steps above, complete with timestamps. That’s your report for clients or management, and your proof if anyone asks later. Second, verify that the account you suspect is actually the right one. I’ve seen an admin delete an account that turned out to be a backup job used by another team. That was a fun call.

Once everything checks out, disable the account in a reversible way first. Lock the password instead of deleting the user. If it turns out you were wrong, rolling back is easy.

passwd -l nguyenhalong

Or, to cut SSH access without touching the password:

mv /home/nguyenhalong/.ssh/authorized_keys /home/nguyenhalong/.ssh/authorized_keys.bak-20260718

Neither of those deletes data; they just close the door. Full account removal with userdel is the absolute last step, and it deserves a more careful decision plus a complete backup. Never jump straight to userdel.

Pro Tips and Warnings From the Trenches

After doing this more times than I can count, here’s what I keep telling my team — and what I hope saves you some pain:

• Schedule an audit at least once a month. Don’t wait for an incident to start caring. Reactive-only auditing means you’re always late. Fifteen minutes with the same checklist is plenty.
• Build a real offboarding process. The moment an employee or contractor leaves, disable the account. Don’t say “next week.” One week is an eternity for someone with bad intentions.
• Never share raw logs publicly. They contain IPs, usernames, and internal patterns. If you want to publish them for learning, sanitize first. This one gets violated constantly, and it never ends well.
• Keep a baseline. Save your first audit output as a comparison point. Deltas from the baseline matter more than the raw list.
• If you run cPanel or any panel, don’t forget to audit at the panel level too. Check out how to check active users in cPanel/WHM.
• And if your team is bigger than one person, write the procedure down. An audit that lives only in one person’s head is fragile — the moment they’re on leave or quit, the process vanishes with them.

And about backups — don’t skip this. It’s not an audit step per se, but if you find something and want to act on it (like disabling an account or removing a key), make sure important data is backed up first. Commands that change or remove access must never run without backup and verification, because permanent data loss is real. For resource-management tips that tie into keeping production healthy, see our troubleshooting high load on cPanel server guide.

FAQ: Auditing User Activity on Linux

Related Articles

• How to Secure SSH Server Against Brute Force
• How to Read and Manage SSH Keys
• Monitoring Server Logs with Journald
• How to Check Active Users in cPanel/WHM
• Troubleshooting High Load on cPanel Server

Please don’t repeat the same mistake. An audit costs fifteen minutes a month, and the payoff for your server’s security is enormous. The Nguyen Hai Long story didn’t have to happen, and yours doesn’t either. Learn these steps, build your offboarding checklist, and take it seriously — because once you let this slide, the hard part isn’t grepping logs. It’s explaining to a client why their data leaked. Found something weird in your own logs? Drop it in the comments, maybe it’ll help someone else too.