last, who, and w Commands in Linux: User Login History

Quick take: last shows login history from /var/log/wtmp. lastb shows failed login attempts. who shows current users. w shows current users plus what they are running and system load.

What Are last, who, and w Commands in Linux?

Three commands cover login and session visibility on Linux: last for history, who for current sessions, and w for current sessions with activity detail. Together they provide a complete audit picture — who has been on the server, who is there now, and what they are doing.

These are the first commands to run during a security incident or routine server audit, because they surface unauthorized access that application logs may not record.

last — Login History

last reads /var/log/wtmp and displays all logins, logouts, and reboots in reverse order.

# Show all login history
last

# Show history for a specific user
last irfan

# Show last 20 entries
last -n 20

# Show full IP addresses (no hostname resolution)
last -i

# Show with full date and time
last -F

# Show system reboots
last reboot

# Show shutdown history
last -x | grep shutdown

Sample output:

irfan    pts/0        192.168.1.10     Tue Apr 22 14:01   still logged in
irfan    pts/0        192.168.1.10     Mon Apr 21 09:15 - 17:30  (08:15)
reboot   system boot  6.8.0-51-generic Mon Apr 21 09:00
root     pts/1        10.0.0.5         Sun Apr 20 22:11 - 22:45  (00:34)

lastb — Failed Logins

lastb reads /var/log/btmp (bad logins) and shows authentication failures — essential for spotting brute force attacks.

# Show failed login attempts (requires root)
sudo lastb

# Show last 30 failed attempts with IPs
sudo lastb -i -n 30

# Count failed attempts by IP
sudo lastb | awk '{print $3}' | sort | uniq -c | sort -rn | head -20

A flood of failures from a single IP is a brute force attempt. Cross-reference with your UFW or Fail2Ban rules to confirm the IP is already blocked.

lastlog — Last Login per User

lastlog shows the most recent login for every account on the system — useful for spotting dormant accounts that should be disabled.

# Show all users' last login
lastlog

# Show for a specific user
lastlog -u irfan

# Show users who have never logged in
lastlog | grep "Never logged in"

who — Current Sessions

who reads /var/run/utmp and lists currently logged-in users.

# Show current logged-in users
who

# Show detailed info including PID
who -u

# Show only your own session
who am i

# Show system boot time
who -b

# Show dead processes and terminal lines
who -d

Sample output:

irfan    pts/0        2026-04-22 14:01 (192.168.1.10)
root     pts/1        2026-04-22 10:30 (10.0.0.5)

w — Sessions with Activity

w is the most information-dense of these commands — it shows who is logged in, from where, how long they have been idle, and what command they are currently running.

# Show all active sessions with current command
w

# Show for a specific user
w irfan

# Show without hostname resolution (faster)
w -i

Sample output:

 14:05:22 up 5:05,  2 users,  load average: 0.12, 0.08, 0.05
USER     TTY      FROM             LOGIN@   IDLE JCPU   PCPU WHAT
irfan    pts/0    192.168.1.10     14:01    0.00s  0.02s  0.00s w
root     pts/1    10.0.0.5         10:30    3:35m  0.01s  0.01s vim /etc/nginx/nginx.conf

The IDLE column shows how long since the user typed anything. The WHAT column shows the current process — useful for seeing if someone is actively working or just connected but idle.

Security Audit Workflow

When auditing a server after a suspected breach, run these in sequence:

# 1. Who is on right now?
w

# 2. Has root logged in recently?
last root | head -20

# 3. Any failed root logins?
sudo lastb root | head -20

# 4. Any logins from unexpected IPs?
last -i | grep -v '192.168\|127.0\|still'

# 5. Any accounts that never log in but show a recent session?
lastlog | grep -v "Never logged in" | grep -v "^Username"

# 6. How many failed attempts and from where?
sudo lastb | awk '{print $3}' | sort | uniq -c | sort -rn | head -10

Security Audit Workflow with last and lastb

Run this sequence after any unplanned access alert or during a routine security review:

#!/bin/bash
# Server access audit — run as root

echo "=== Current sessions ==="
w

echo ""
echo "=== Logins in last 7 days ==="
last -n 50 -F | grep -v "^$"

echo ""
echo "=== Failed login attempts (last 30) ==="
lastb -i -n 30 2>/dev/null || echo "(requires root)"

echo ""
echo "=== Top 10 IPs with failed logins ==="
lastb 2>/dev/null | awk 'NF>1 {print $3}' | grep -E "^[0-9]" |   sort | uniq -c | sort -rn | head -10

echo ""
echo "=== Accounts that have never logged in (potential stale accounts) ==="
lastlog | grep "Never logged in"

echo ""
echo "=== Last login per user ==="
lastlog | grep -v "Never" | grep -v "^Username"

Deep Inspection with utmpdump

utmpdump dumps the raw binary login database files in human-readable format. Useful when you need to parse login data programmatically or investigate potential log tampering:

# Dump current login sessions (utmp)
utmpdump /var/run/utmp

# Dump login history (wtmp)
utmpdump /var/log/wtmp | tail -30

# Dump failed login history (btmp)
sudo utmpdump /var/log/btmp | tail -30

# Check if wtmp has been tampered with (unusual gaps in timestamps)
utmpdump /var/log/wtmp | awk '{print $4}' | sort | uniq -c | sort -rn | head -5

Integrating with Fail2Ban

After identifying attacking IPs with lastb, verify they are already blocked by Fail2Ban or add them manually:

# Check Fail2Ban status for SSH jail
sudo fail2ban-client status sshd

# Check if a specific IP is banned
sudo fail2ban-client get sshd banip | grep 185.220.101.5

# Manually ban an IP from lastb output
ATTACKING_IP="185.220.101.5"
sudo fail2ban-client set sshd banip "$ATTACKING_IP"

# Permanently block via UFW if Fail2Ban is not installed
sudo ufw deny from 185.220.101.5 to any
sudo ufw status numbered

Common Issues and Notes

Reference: last man page — man7.org. Tested on Ubuntu 22.04 LTS with util-linux 2.37.2.

Final Thoughts

These three commands — last, who, and w — cost nothing to run and reveal a great deal about who has been accessing your server. Make them part of your standard server audit checklist. For persistent monitoring, pair them with Fail2Ban for automatic IP blocking and centralized logging to preserve wtmp records beyond their local rotation window.