• Ubuntu typically writes privileged authentication events to /var/log/auth.log and also stores structured copies in systemd journals (query with journalctl).
• last and lastlog summarize login history using /var/log/wtmp and /var/log/lastlog, not the old incorrect paths under /etc/log/.
• PAM lines in auth.log describe session open and close events; failed password attempts and sudo denials are separate high-signal patterns to watch.
• grep, awk, and time-bounded journalctl queries are the usual way to hunt for SSH abuse and privilege escalation before you add fail2ban or centralized logging.

auth.log and the logging pipeline

On most Ubuntu servers, rsyslog receives syslog messages and writes security-related lines to /var/log/auth.log. The Pluggable Authentication Modules (PAM) stack decides whether a login or sudo request succeeds; PAM and SSH then emit syslog lines that rsyslog routes into that file.

systemd-journald also captures the same services. That means you can inspect recent events with either plain text files or journalctl, depending on which tool fits your workflow.

On Ubuntu 24.04 and 22.04, /var/log/auth.log is present when rsyslog is installed and running. On minimal images, auth.log may not exist. In that case, use journalctl (next section), or install rsyslog:

ls -l /var/log/auth.log
sudo systemctl status rsyslog

sudo apt update
sudo apt install rsyslog
sudo systemctl enable --now rsyslog

auth.log compared to syslog

If you need the full story for a time window, start with auth.log for security-relevant lines, then widen to syslog when you troubleshoot services that are not strictly authentication.

Binary login databases

Tools such as last read /var/log/wtmp (not /etc/log/wtmp). The lastlog command reads /var/log/lastlog (not /etc/log/lastlog). Those paths are easy to mistype; the correct locations live under /var/log/.

To page through the authorization log:

sudo less /var/log/auth.log

Example lines (your hostnames and times will differ):

May  3 18:20:45 host sshd[585]: Server listening on 0.0.0.0 port 22.
May  3 18:23:56 host login[673]: pam_unix(login:session): session opened for root
Sep  5 13:49:07 host sshd[358]: Received signal 15; terminating.

Press q to quit less.

Follow new events as they arrive:

sudo tail -f /var/log/auth.log

Stop with Ctrl+C. This is the quickest way to watch a live SSH attack or test whether your key-based login produces the lines you expect.

journalctl reads the systemd journal. It shines when you want systemd units, boots, or compact time ranges. For SSH on Ubuntu, the service is usually named ssh:

journalctl -u ssh

You can also filter by unit explicitly:

journalctl _SYSTEMD_UNIT=ssh.service

If journalctl -u ssh returns no entries, confirm the unit name on your system. Some distributions use sshd instead:

sudo systemctl status ssh
sudo systemctl status sshd

Limit output to the last hour or day:

journalctl -u ssh --since "1 hour ago"
journalctl -u ssh --since today

For a deeper guide to options, filters, and export patterns, read How To Use journalctl To View and Manipulate Systemd Logs.

last shows recent logins and reboots using data in /var/log/wtmp:

last

Example output:

demoer   pts/1        203.0.113.10 Thu Sep  5 19:37   still logged in
root     pts/0        203.0.113.10 Thu Sep  5 19:15   still logged in

The still logged in marker means a session is active. Closed sessions show start and end times.

lastlog prints the most recent login per local user by combining /var/log/lastlog with /etc/passwd:

lastlog

System accounts often show Never logged in, which is expected when those accounts are not used for interactive login.

Failed SSH password attempts usually contain Failed password or authentication failure, depending on configuration. Quick checks:

sudo grep "Failed password" /var/log/auth.log
sudo grep "authentication failure" /var/log/auth.log

Or with the journal:

journalctl -u ssh --since today | grep -i "failed"

A sustained burst of failures from one address is a strong sign of automated brute force traffic. Pair log review with network controls: How To Set Up a Firewall with UFW on Ubuntu explains host-level filtering on your Droplet.

sudo and su both emit lines you can track.

Common patterns:

sudo grep "sudo:" /var/log/auth.log
sudo grep "COMMAND=" /var/log/auth.log
sudo grep -E "su\[|su:" /var/log/auth.log

COMMAND= appears in many sudo configurations and records which binary ran. Investigate unexpected users, hosts, or binaries immediately.

PAM sits between applications such as sshd and your account database. A typical session line looks like this:

May  3 18:23:56 host sshd[12345]: pam_unix(sshd:session): session opened for demoer

Rough field map:

• Timestamp and host: when and where the event occurred.
• Process: sshd with a PID in brackets.
• PAM stack and result: pam_unix or other modules, plus session opened or session closed.
• Subject: which Unix user gained a session.

Authentication failures often show auth failure, Failed password, or authentication failure rather than a session open. Pair PAM context with SSH messages so you do not confuse a successful session with a failed password.

grep is enough for many hunts:

sudo grep -E "sshd|sudo|su" /var/log/auth.log | tail -n 50

awk helps when columns matter:

sudo awk '/Failed password/ {print $0}' /var/log/auth.log

Add /etc/passwd and group lookups only when you need to map UIDs to names; the logs usually print names directly.

fail2ban watches auth.log (or the journal, depending on backend) and updates firewall rules after repeated failures.

Install and enable the service:

sudo apt update
sudo apt install fail2ban
sudo systemctl enable --now fail2ban

A minimal jail for SSH often lives in /etc/fail2ban/jail.d/defaults-debian.conf or a custom file under /etc/fail2ban/jail.d/. Ensure the sshd jail is enabled = true, then check status:

sudo fail2ban-client status
sudo fail2ban-client status sshd

For a full walkthrough with ban times and mail actions, follow How To Protect SSH with Fail2Ban on Ubuntu 22.04. Combine it with UFW so both network policy and automated bans align.

Ubuntu rotates /var/log/auth.log through logrotate, commonly driven from /etc/logrotate.d/rsyslog. Typical settings compress old files and keep several weeks on disk, but vendors change defaults, so always read the active file:

cat /etc/logrotate.d/rsyslog

For background on rotation concepts, see How To Manage Logfiles With Logrotate on Ubuntu 16.04 (the ideas apply to current releases even though the title references 16.04).

Production teams often ship auth logs to a central SIEM or backup cluster. At a high level you can:

• Use journald forwarding or rsyslog rules to relay syslog facilities to a remote collector.
• Export snapshots with journalctl when you only need an evidence bundle.

For Linux-wide logging concepts on Ubuntu, read How To View and Configure Linux Logs on Ubuntu and CentOS. Wire transport security (VPN or TLS) before you send logs across the public internet.

1. Where is the authentication log file located on Ubuntu?

The primary text file is /var/log/auth.log on default Ubuntu images that use rsyslog. Always confirm with ls -l /var/log/auth.log on your own host.

2. What is the difference between auth.log and syslog on Ubuntu?

auth.log focuses on authentication and privilege events. /var/log/syslog collects a wider slice of daemon and system messages. Overlap depends on rsyslog rules, but security reviews usually start in auth.log.

3. How do I check who logged into my Ubuntu server?

Run last for interactive sessions, lastlog for per-account summaries, and search auth.log or journalctl -u ssh when you need the exact SSH event stream.

4. How do I detect an SSH brute force attack on Ubuntu?

Look for bursts of Failed password or authentication failure messages from similar time windows and source IPs. Combine log review with UFW rules and fail2ban jails.

5. Does Ubuntu 24.04 still use auth.log?

Yes, when rsyslog is installed and running. Ubuntu also stores authentication events in the systemd journal, so journalctl queries work even if auth.log is missing on a minimal image.

6. How do I stop repeated failed login attempts automatically?

Install and configure fail2ban so repeated failures trigger temporary bans. Harden SSH (keys, non-default port, AllowUsers) in parallel.

7. How long does Ubuntu keep auth.log data by default?

Retention depends on logrotate settings and disk space. Inspect /etc/logrotate.d/rsyslog and archived files such as /var/log/auth.log.* to see how many rotated copies remain on your server.

8. How do I track sudo command usage on Ubuntu?

Search for sudo: and COMMAND= in /var/log/auth.log, and review journalctl output if sudo logging targets the journal on your image.

When you monitor system authentication logs on Ubuntu, you combine file paths, journal queries, and simple text filters to understand who accessed the host and whether privilege use looks normal. Layer automation with fail2ban, firewall rules, and centralized forwarding as your environment matures.

To manage accounts referenced in those logs, see How To Add and Delete Users on Ubuntu or How To Create a New Sudo-Enabled User on Ubuntu.

Continue with DigitalOcean

Ship monitoring that matches your team size. DigitalOcean Monitoring adds graphs and alerting for Droplets and supported services so you notice CPU, memory, and disk issues around the same time you review auth trails. For always-on workloads, Droplets give you full Linux control to tune SSH, fail2ban, and rsyslog exactly how your security team expects.