Sr Technical Writer and Team Lead Monitoring system authentication logs on Ubuntu helps you spot stolen passwords, SSH brute force attempts, and unexpected sudo use. This guide shows where those records live, how to read them with classic files and journalctl, and how to pair filtering with fail2ban and firewall basics. This tutorial was validated on Ubuntu 24.04 LTS and Ubuntu 22.04 LTS. Commands should also work on newer Ubuntu releases that use systemd. You can follow along on a recent Ubuntu LTS server. If you need a fresh host, complete Initial Server Setup with Ubuntu first. 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: 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. 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: Example lines (your hostnames and times will differ): Press q to quit less. Follow new events as they arrive: 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: You can also filter by unit explicitly: If journalctl -u ssh returns no entries, confirm the unit name on your system. Some distributions use sshd instead: Limit output to the last hour or day: 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: 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: 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: 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. 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: 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: awk helps when columns matter: 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: 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: 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: 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: 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. 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. 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. 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. 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. 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. Install and configure fail2ban so repeated failures trigger temporary bans. Harden SSH (keys, non-default port, AllowUsers) in parallel. 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. 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. 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. Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases. Learn more about our products I help Businesses scale with AI x SEO x (authentic) Content that revives traffic and keeps leads flowing | 3,000,000+ Average monthly readers on Medium | Sr Technical Writer(Team Lead) @ DigitalOcean | Ex-Cloud Consultant @ AMEX | Ex-Site Reliability Engineer(DevOps)@Nutanix This textbox defaults to using Markdown to format your answer. You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link! Looks like you need to update your href’s to the previous articles to use www.digitalocean.com instead of atlantis.digitalocean.com. Say, someone manages to break into my server eventually. Can he remove certain parts from the access logs? If so, how do I figure that out and more importantly, protect myself against such malicious file-editing? wow log has what look like constant, huge numbers of attempts to login by hackers. literally 1000’s per day. There is a small typo at the beginning of the section “How To Use the “lastlog” Command”. In the phrase “This information is provided by accessing the /etc/log/lastlog file” the correct path should be /var/log/lastlog. Please complete your information! Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation. Full documentation for every DigitalOcean product. The Wave has everything you need to know about building a business, from raising funding to marketing your product. Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter. New accounts only. By submitting your email you agree to our Privacy Policy Scale up as you grow — whether you're running one virtual machine or ten thousand. Sign up and get $200 in credit for your first 60 days with DigitalOcean.* *This promotional offer applies to new accounts only.