Auditing User Logins

Knowing who logged in, from where, at what time, and what they did is fundamental to system security. Ubuntu records login activity in multiple places: the wtmp and btmp binary files (accessed via last and lastb), /var/log/auth.log (text), and the systemd journal. For comprehensive auditing, the Linux Audit System (auditd) provides tamper-resistant, structured records.

Quick login history commands

# Show login history (from /var/log/wtmp)
last

# Show last 20 logins
last -n 20

# Show login history for a specific user
last irfan

# Show current logged-in users
who
w    # More detailed: shows what they are doing

# Show last login for all users (from /var/log/lastlog)
lastlog

# Show failed login attempts (from /var/log/btmp)
sudo lastb | head -20

# Show who is currently logged in
users

last output

irfan    pts/0        192.168.1.45     Mon Jun  1 14:00 - 15:30  (01:30)
deploy   pts/1        10.0.0.5         Mon Jun  1 12:00 - 12:10  (00:10)
reboot   system boot  5.15.0-105       Mon Jun  1 08:00
wtmp begins Sun May 31 00:00:00 2024

Reading auth.log

# View recent authentication events
sudo tail -50 /var/log/auth.log

# Filter for SSH logins only
sudo grep "sshd" /var/log/auth.log | grep "Accepted" | tail -20

# Find failed SSH login attempts
sudo grep "Failed password" /var/log/auth.log | tail -20

# Find accounts being probed (invalid users)
sudo grep "Invalid user" /var/log/auth.log | awk '{print $8}' | sort | uniq -c | sort -rn | head -10

# Find IP addresses with most failed attempts (potential attackers)
sudo grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -10

Example: top IPs with failed logins

    142 45.142.212.100
     87 185.162.235.56
     43 103.127.124.19

Auditing with journald

# View SSH login events in the journal (more structured than auth.log)
sudo journalctl -u ssh --since "2024-06-01" | grep -E "Accepted|Failed"

# See all authentication events today
sudo journalctl --since today | grep -E "pam|sudo|sshd"

# Follow live authentication events
sudo journalctl -f -u ssh

# Show all sudo commands run in the last 24 hours
sudo journalctl --since "24 hours ago" | grep "sudo"

Enabling the Linux Audit System

For compliance-grade auditing (PCI-DSS, SOC2, CIS benchmark), install auditd. It records all syscalls and access to specified files in a tamper-resistant log.

# Install auditd
sudo apt install auditd audispd-plugins

# Enable and start
sudo systemctl enable --now auditd

# Add rules to monitor file access and command execution
sudo auditctl -w /etc/passwd -p wa -k identity    # Watch /etc/passwd writes
sudo auditctl -w /etc/shadow -p wa -k identity    # Watch /etc/shadow writes
sudo auditctl -w /etc/sudoers -p wa -k sudoers    # Watch sudoers changes
sudo auditctl -a always,exit -F arch=b64 -S execve -k exec  # Log all commands

# View audit log
sudo ausearch -k identity | tail -20
sudo ausearch -k exec --start today | tail -20

# Generate audit report
sudo aureport --auth --summary    # Authentication summary
sudo aureport --failed            # Failed events

Detecting suspicious logins

# Check for logins at unusual hours
last | awk '{ if($6 >= "00:00" && $6 <= "06:00") print }' | head -20

# Find users who have never logged in (potential stale accounts)
lastlog | grep "Never logged in"

# Find accounts with recent first-time logins (new account activity)
lastlog | sort -k4 | tail -20

# Send an email alert when a user logs in (add to /etc/pam.d/sshd)
# session optional pam_exec.so /usr/local/bin/login-alert.sh

# Simple login alert script /usr/local/bin/login-alert.sh:
# #!/bin/bash
# echo "Login: $PAM_USER from $PAM_RHOST at $(date)" | mail -s "Login Alert" admin@company.com

Conclusion

Start with last, lastb, and grep "Accepted\|Failed" /var/log/auth.log for quick login investigation. For structured, compliance-grade auditing, install auditd and configure rules for /etc/passwd, /etc/shadow, /etc/sudoers, and command execution. Review failed login source IPs regularly and consider blocking persistent attackers with fail2ban or UFW rules.

FAQ

Is Auditing User Logins important for Ubuntu administrators?+

Yes. It supports practical Ubuntu administration because it connects directly to server reliability, security, troubleshooting, or daily operations.

Should I practice this on a live server?+

Use a lab VM first. After you understand the command output and rollback path, apply the workflow carefully on real systems.

What should I do after reading this article?+

Run the practice commands, write down what each one shows, and continue to the next article in the Ubuntu roadmap.

Need help with Ubuntu administration?

Work directly with Muhammad Irfan Aslam for Ubuntu Server, Linux, cloud, Docker, DevOps, CI/CD, or infrastructure troubleshooting support.

Hire Me for Support