Linux users: useful commands to list accounts and identify access

When you take over a Linux server, the first question isn’t always “who’s connected now?”. The real question is often: which accounts still existwhich ones can log in, and which ones have sensitive rights.

In this guide, we’ll list the users neatly, without panicking. /etc/passwdThen, identify the accounts that need to be checked first. Let me tell you right now: don’t delete anything just because a name seems strange. On Linux, many accounts are for services.

Read /etc/passwd without confusing the system account and the human user account.

The file /etc/passwd Lists locally known accounts. It does not contain passwords in plain text, but it provides useful information: account name, UID, GID, home directory and shell.

cat /etc/passwd

A line looks like this:

nathan:x:1000:1000:Nathan Martin:/home/nathan:/bin/bash

The fields are separated by colons. For a first look, focus on the name, UID, home directory, and shell:

cut -d: -f1,3,6,7 /etc/passwd

On many distributions, user accounts begin with the UID. one thousandSystem accounts often have a lower UID, or a shell like /usr/sbin/nologin Or /bin/falseThis is not a universal rule, but it is a good first filter.

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

The manual page of passwd(5) It details the exact file format. Keep it handy if you need to audit an old server or a somewhat unusual distribution.

Prefer getent when accounts are not only local

In a simple position, /etc/passwd Often this is sufficient. On a server integrated with LDAP, Active Directory, SSSD, or another directory, it may be incomplete. In that case, use getent, which queries the databases configured by the system.

getent passwd

To check a specific account:

getent passwd nathan

And to generate a more readable list of accounts with user UIDs:

getent passwd | awk -F: '$3 >= 1000 && $3 < 60000 {print $1, $3, $6, $7}'

I prefer this method on corporate machines because it avoids the assumption that an account doesn't exist simply because it's not written to the local file. The command is documented in getent(1).

Check sensitive groups and permissions

Listing accounts is good. Knowing which ones can cause damage is better. Start with a specific user with id :

id nathan
groups nathan

You will see the UID, the primary group, and the secondary groups. The groups to look at closely depend on the distribution, but sudo, wheel, adm, docker or certain application groups can provide much more than just simple user access.

getent group sudo
getent group wheel
getent group docker
getent group adm

If an account appears in sudo Or wheelAlso check the sudoers configuration. An old, forgotten account with admin access is exactly the kind of detail that will come back to bite you later. On this point, our guide for mastering sudo under Linux This initial check is a good complement.

Orders id(1) And groups(1) They remain simple, but they quickly give an idea of ​​the real scope of an account.

Identify the accounts that can log in

Not all listed accounts are for logging in. To isolate those with a current interactive shell, you can filter the shells:

getent passwd | grep -E '/bin/(bash|sh|zsh|fish)$'

This filter isn't perfect, but it provides an initial list to review. Next, check if the accounts have a personal folder:

getent passwd | awk -F: '$6 ~ /^/home/ {print $1, $6, $7}'
ls -1 /home

If you are auditing a server exposed via SSH, also check the keys present in the user directories:

sudo find /home -maxdepth 3 -path '*/.ssh/authorized_keys' -type f -ls

An SSH key in the wrong account can be enough to maintain access. If you need to clean up your authentication settings, also reread our article on generating an SSH key on Ubuntu.

Check the latest connections without jumping to conclusions too quickly

To see who is online now:

who
w

For recent history:

last -a | head
sudo lastlog | head -30

lastlog This may indicate that an account has never been logged in, but that's not enough to prove it's useless. An account might be used for a service, a scheduled task, an application, or it might have been created for a backup procedure. Use these commands as signals, not as an automatic decision. The page lastlog(8) specifies the available options.

If you are looking for an anomaly after a suspicious connection, supplement this with the system logs:

sudo journalctl -u ssh -b
sudo journalctl -p warning..alert -b

Our guide to journalctl and the logs from the last startup can help to frame this part without searching randomly.

The little checklist I would use before cleaning

• Exact slug of the account Note the name, UID, home directory, and shell.
• Sensitive groups : control sudo, wheel, docker, adm and application groups.
• SSH access : search for files authorized_keys and keep a copy before making any changes.
• Last activity : cross last, lastlog and the newspapers, without removing them based on a single clue.
• Related service : check if the account belongs to a service or application before disabling it.

If an account seems truly unnecessary, start by locking it or disabling its login, not by deleting its folder. On a server, I always prefer to keep track, test the services, and only then clean things up. It's less dramatic, but it prevents breaking an application because an "unknown" account was actually being used daily.

sudo passwd -l old_account
sudo systemctl --failed
sudo journalctl -p warning..alert -b

After this check, you will have a much clearer view: human accounts, system accounts, admin rights, SSH access, and recent activity. To link this check to active services, you can then use the list of systemctl services and see what's really running on the machine.

sudo apt update && sudo apt upgrade