Linux Security

Check failed SSH login attempts on Linux

See who is hammering SSH and whether your keys are enough.

10 min read Beginner Updated 9 Jun 2026

Step-by-step guide

Work through each section in order. Stop when your issue is resolved — you do not need every step for every situation.

Warning

Failed login logs may contain attacker-chosen usernames — treat exported logs as sensitive. If brute-force volume is high, fix SSH hardening before exposing logs externally.

What you will achieve

Review SSH authentication failures on Ubuntu and Debian to spot brute-force patterns, confirm password logins are disabled, and decide whether fail2ban or firewall limits are needed.

1) Recent SSH failures via journalctl

On systemd systems (Ubuntu 22.04+, Debian 12+), sshd logs to the journal:

sudo journalctl -u ssh -u sshd --since "24 hours ago" | grep -i "failed\|invalid"
sudo journalctl -u ssh -u sshd --since today -p err

Ubuntu names the unit ssh; some Debian installs use sshd. Query both to be safe.

2) Count failures by source IP

sudo journalctl -u ssh --since "7 days ago" --no-pager | \
  grep -i "Failed password" | \
  awk '{for(i=1;i<=NF;i++) if($i=="from") print $(i+1)}' | \
  sort | uniq -c | sort -rn | head -20

Top IPs hammering your server deserve firewall blocks or fail2ban jails.

3) Use lastb for btmp records

sudo lastb | head -30
sudo lastb -f /var/log/btmp.1 | head -20

lastb reads failed login records. Rotated files live as btmp.1. Empty output may mean logging disabled or no password attempts (good if you use keys only).

4) Check auth.log on older setups

sudo grep "Failed password" /var/log/auth.log | tail -50
sudo grep "Invalid user" /var/log/auth.log | wc -l

Invalid user lines reveal bots probing random usernames like admin and oracle.

5) Successful vs failed ratio

sudo journalctl -u ssh --since "7 days ago" | grep -c "Accepted publickey"
sudo journalctl -u ssh --since "7 days ago" | grep -c "Failed password"

High failure count with zero accepted password logins confirms keys-only auth is working — failures are noise unless volume causes log disk use.

6) Respond to patterns

Ensure PasswordAuthentication no and PermitRootLogin no in /etc/ssh/sshd_config. Consider fail2ban, UFW rate limits, or moving SSH off port 22 only as obscurity — real fixes are keys and firewall policy.

Verify

sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin'
sudo fail2ban-client status sshd 2>/dev/null || echo "fail2ban not installed"

After hardening, failure rate should not translate into successful intrusions — monitor weekly.

Related guides

journalctl security ssh