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.