lastb lists failed login records, with data from /var/log/btmp—the binary log dedicated to failed logins. For investigating SSH brute-forcing or confirming “who has been trying to log in lately,” start with this command. The usage and behavior below were tested in a Rocky 9 container: an sshd was stood up, several real logins were attempted with wrong passwords, and all output comes from that reproduction.

Basic Usage

Run it directly—one failed login per line: username, terminal, source address, time. In the container, one wrong-password attempt each was fired at root and admin, and lastb recorded both faithfully:

Figure 1

ssh:notty means the SSH login never got a terminal—a telltale sign of brute-forcing, since a normal interactive login has a pts/N terminal name. The ::1 in the source column is IPv6 localhost; in a real brute-force scenario that column fills up with assorted unfamiliar public IPs.

Common Options

Option Effect Example
-n N / -N Show only the most recent N entries (-1 is the shorthand) lastb -n 5
-d Resolve IPs back to hostnames (PTR lookup) lastb -d
-a Move the hostname column to the end lastb -a
-F Show full start/end dates and times lastb -F
-s / -t Filter by start/end time lastb -s 20240101000000
-f FILE Read a different file (e.g. the rotated btmp.1) lastb -f /var/log/btmp.1
-R Hide the hostname column lastb -R

Investigation habit: start with lastb -n 20 to see recent source IPs, then tally the high-frequency sources. Note that the counting pipeline hides a small pit found in testing—the btmp begins ... trailing line at the end of lastb output mixes into the results (the extra 1 btmp in Figure 2 is exactly it). Limiting entries with -n both avoids the trailing line and keeps large files from flooding the terminal—more reliable than a bare pipe:

Figure 2

btmp records only failed logins; the login logs are a family of files, each with its own job:

File Contents Corresponding Command
/var/log/btmp Failed logins only lastb
/var/log/wtmp Historical + current logins (the archive of utmp) last
/var/run/utmp Currently online users, boot time uptime, who

Two related commands as well:

Command Effect in One Line
lastlog Each user’s most recent login time and source
utmpdump Converts btmp/wtmp binaries to text (-r writes back)

If you can’t tell which ledger a record went into, remember it by the tested contrast: wrong-password attempts go into btmp (visible via lastb), successful logins go into wtmp (visible via last). In Figure 2, after testu logged in successfully, last showed a pts/1 record—the mirror image of lastb‘s ssh:notty.

Pitfall Warnings

  • btmp can grow very large: on heavily brute-forced machines it can pile up past a gigabyte within days—cap it with -n first, and never dump the whole thing to the terminal.
  • Root privileges are required: btmp defaults to 0660 root:utmp (confirmed with stat -c '%a %U:%G' in testing); a regular user running lastb reads nothing.
  • Don’t forget the trailing line in your tallies: the btmp begins ... trailer and the final blank line will mix into awk statistics—limit with -n, or filter with grep -v '^btmp' before counting.
  • Many failures ≠ compromised: failed records on a public-facing machine are normal. What deserves action is sustained high-frequency failures from unfamiliar IPs—pair that with automatic banning via fail2ban or similar, and check last to confirm no successful login slipped through.

This article was rewritten from the author’s CSDN blog posts originally published between 2020 and 2024.