How to See Who Logged In to Your Linux Server (last, who, auth Logs and sudo History)
Security isn't only about keeping people out; it's about knowing who got in. Linux records every login, every failed attempt and every sudo command, and the tools to read those records are already installed. Five commands, and a five-minute monthly habit that would catch most problems while they're still small.
Quick reference
| Question | Command | |
|---|---|---|
| Who's logged in right now? | who or w | |
| Recent logins, with IPs | last -n 20 -a | |
| Last login per user | lastlog | |
| Failed logins | sudo lastb -n 20 or `journalctl -u ssh | grep Failed` |
| Every sudo command | journalctl _COMM=sudo | |
| Reboots | last reboot |
1. Right now
w
Each line is a session: user, terminal, where from, login time, and what they're running. Yourself over SSH is normal. Someone else, or a second session of you from an IP you don't know, is not.
2. Recent logins
last -n 30 -a
Newest first: user, terminal, login and logout times, and the source IP at the end of each line (-a puts it there). still logged in marks current sessions. last john for one user; last -s -7days for the past week.
lastlog
shows the most recent login for every account on the system — a quick way to spot an account that should never log in (www-data, backup) having done so.
3. Failed attempts
sudo lastb -n 20 -a
The failures. On a server reachable from the internet this is long and boring — bots trying root and admin — which is exactly what Fail2ban (tutorial 7) handles. What you're looking for is failures against your username from an address that isn't yours.
From the journal, with more detail:
journalctl -u ssh --since "7 days ago" | grep -E "Failed|Invalid" | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head
Top ten attacking addresses this week.
4. Successful SSH logins and their keys
journalctl -u ssh --since "30 days ago" | grep "Accepted"
Each line says Accepted publickey for john from 192.168.1.20 with the key's fingerprint. Compare fingerprints to your known keys (ssh-keygen -lf ~/.ssh/id_ed25519.pub on each laptop). A fingerprint you don't recognise means a key you didn't add — check ~/.ssh/authorized_keys immediately.
5. What was done with sudo
journalctl _COMM=sudo --since "7 days ago"
Every sudo command, by whom, in which directory. The thing to look for is commands you didn't run: user additions, key changes, firewall changes.
6. Reboots and shutdowns
last reboot
last shutdown
journalctl --list-boots
A reboot you didn't do is either a power cut, unattended-upgrades (check its log), or a problem.
The monthly five minutes
w
last -n 20 -a
sudo lastb -n 10 -a
journalctl -u ssh --since "30 days ago" | grep Accepted | awk '{print $9, $11, $NF}' | sort | uniq -c
journalctl _COMM=sudo --since "30 days ago" | grep -v "session" | tail -n 30
cat ~/.ssh/authorized_keys
getent group sudo
Unknown IP, unknown fingerprint, unknown key, unknown sudo member — any one of those is worth stopping to understand. Nothing unknown: close the window.
Watch it live
journalctl -u ssh -f
in a tmux window while you work. Watching the bots bounce off is oddly reassuring.
Troubleshooting
last shows nothing or "wtmp begins" recently. The file rotates monthly; last -f /var/log/wtmp.1 reads the previous one.
lastb is empty. No failures recorded, or btmp isn't being written (sudo touch /var/log/btmp).
Logins from ::1 or 127.0.0.1. Local tunnels or a tool on the server logging in to itself; usually your own doing.
Can't tell which key is which. Add comments at the end of each line in authorized_keys (... john-laptop), and ssh-keygen -lf to map fingerprints.
Wrapping up
w for now, last -a for then, lastb for who tried, journalctl -u ssh | grep Accepted for which key, journalctl _COMM=sudo for what they did. Five minutes a month. Most break-ins sit unnoticed for weeks; this is how you make sure yours wouldn't.
