How to Read Auth Logs and Spot SSH Break-In Attempts

This guide shows you how to read authentication logs on a Linux server and identify signs of SSH break-in attempts. You’ll learn where the logs live, what normal entries look like, and which patterns indicate brute-force attacks, credential stuffing, or unauthorized access. By the end, you’ll be able to spot suspicious activity and take basic protective steps.

What You’ll Need

• Access to a Linux server (Ubuntu, Debian, CentOS, or similar) with SSH enabled.
• Root or sudo privileges to read log files.
• Basic familiarity with the command line and text editing.

Step-by-Step

1. Locate the auth log. On most Debian/Ubuntu systems, authentication logs are in /var/log/auth.log. On RHEL/CentOS/Fedora, they are in /var/log/secure. If you’re unsure, run sudo ls /var/log/ | grep -i auth or sudo ls /var/log/ | grep -i secure.
2. Open the log with a pager. Use sudo less /var/log/auth.log (or secure). This allows you to scroll and search. Press Shift+G to jump to the end, where the newest entries are.
3. Understand the basic format. Each line typically looks like:
   Jan 5 14:22:31 server sshd[1234]: Failed password for invalid user admin from 203.0.113.5 port 54321 ssh2
   The date, hostname, process (sshd), PID, and message are separated by spaces. Focus on the message part after the PID.
4. Identify successful logins. Look for lines containing Accepted password for or Accepted publickey for. These are successful SSH logins. Note the username, source IP, and time. Compare them against your own activity or scheduled tasks.
5. Spot failed password attempts. Lines with Failed password for indicate a wrong password or username. A single failed attempt is normal (typos happen), but many from the same IP or targeting multiple users is a red flag.
6. Look for invalid usernames. Messages like Failed password for invalid user mean the SSH client tried a username that doesn’t exist on your system. Attackers often scan for default accounts like admin, root, or test. A high count of invalid users is a strong sign of a brute-force attack.
7. Check for repeated attempts from one IP. Use sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr to list source IPs by number of failures. The $(NF-3) extracts the IP address (the fourth field from the end). If one IP has dozens or hundreds of attempts, that’s a brute-force attack.
8. Look for time-based patterns. Brute-force attacks often occur in bursts. Check if failures are clustered in a short window (e.g., 100 attempts in 5 minutes). You can use sudo grep "Failed password" /var/log/auth.log | tail -200 to see recent activity and gauge frequency.
9. Watch for unusual usernames. Attackers often try names like oracle, ubuntu, pi, or user. If you see a pattern of usernames that don’t match your legitimate users, treat it as suspicious.
10. Check for disconnection messages. Lines with Connection closed by authenticating user or Connection reset by peer may indicate an attacker who gave up or was blocked. They can also appear after a successful login if the session ends abruptly.
11. Look for sudo usage. After a successful login, an attacker may try to escalate privileges. Search for sudo in the auth log (e.g., sudo grep "sudo" /var/log/auth.log) to see commands run with elevated privileges. Look for unexpected sudo commands, especially from non-admin users.
12. Check for service restarts or errors. Lines like Server listening on 0.0.0.0 port 22 are normal, but repeated fatal: errors or error: PAM messages could indicate misconfiguration or an attack vector.
13. Use log rotation awareness. Auth logs rotate (e.g., auth.log.1, auth.log.2.gz). If you suspect an attack that happened days ago, check the rotated logs with sudo zcat /var/log/auth.log.2.gz | grep "Failed password".
14. Take action if you find suspicious activity. If you identify a brute-force attack, you can block the offending IP with a firewall rule (e.g., sudo ufw deny from 203.0.113.5). Also consider disabling password authentication and using SSH keys only (edit /etc/ssh/sshd_config and set PasswordAuthentication no).

Common Mistakes

• Ignoring the ‘invalid user’ messages. Some admins think only ‘Failed password’ matters, but invalid usernames are a clear sign of automated scanning.
• Confusing the IP field. The IP address is not always the last field; it’s the fourth from the end in the standard message. Using the wrong field in awk can give you the port or protocol instead.
• Not checking rotated logs. If you only look at the current log, you might miss attacks that happened days ago.
• Assuming all failed attempts are attacks. A few failures from your own IP could be a forgotten password. Correlate with your own activity before blocking.
• Overlooking successful logins from unknown IPs. A single ‘Accepted’ from an unfamiliar IP is more serious than a thousand failures, because it means the attacker got in.

Tips

• Use SSH key authentication. Keys are far harder to brute-force than passwords. Disable password auth if possible.
• Install fail2ban. This tool automatically blocks IPs after repeated failures. It’s available in most distro repos and works with auth logs.
• Change the SSH port. Moving SSH from port 22 to a non-standard port reduces automated attacks, though it’s not a security measure by itself.
• Set up log monitoring. Use a tool like logwatch or a simple cron job to email you daily summaries of auth log activity.
• Use journalctl if you use systemd. On many systems, sudo journalctl -u ssh shows SSH logs in a more readable format.

Troubleshooting

• Log file is empty or missing. Ensure rsyslog or syslog-ng is running. If not, install and start it. On some minimal systems, auth logging is disabled; check /etc/rsyslog.conf or /etc/rsyslog.d/50-default.conf for a line like auth,authpriv.* /var/log/auth.log.
• You see ‘Permission denied’ when reading logs. Use sudo. If you still get permission denied, the file may be owned by a special group; add your user to the adm group (Debian/Ubuntu) or wheel (RHEL) and log out/in.
• The log is too large to search manually. Use grep with patterns. For example, sudo grep "Failed password" /var/log/auth.log | tail -100 shows the last 100 failures. Use head for the first 100.
• You see many ‘Connection closed’ messages but no failures. This could be a port scan or a misconfigured client. Check if the IPs are from known scanners (e.g., Shodan) and block them if needed.
• SSH service is not logging at all. Check sudo systemctl status ssh or sudo service ssh status. Ensure LogLevel VERBOSE is set in /etc/ssh/sshd_config (default is INFO, which is fine). Restart sshd after changes.

Frequently Asked Questions

Q: How can I tell if an SSH break-in attempt was successful?
A: Look for ‘Accepted’ lines. If you see an ‘Accepted password’ or ‘Accepted publickey’ from an IP you don’t recognize, that’s a successful login. Immediately check for unusual activity, change passwords, and review sudo logs.

Q: What is the difference between ‘invalid user’ and ‘Failed password’?
A: ‘Invalid user’ means the username doesn’t exist on the system. ‘Failed password’ means the username exists but the password was wrong. Both are signs of an attack, but ‘invalid user’ is more indicative of automated scanning.

Q: How many failed attempts is considered an attack?
A: There’s no hard number, but more than 5-10 from a single IP in a short time is suspicious. Automated attacks often produce dozens or hundreds. Use your judgment and consider your server’s exposure.

Q: Can I block an IP permanently?
A: Yes, you can add a firewall rule. For example, sudo ufw deny from 203.0.113.5 (Ubuntu) or sudo iptables -A INPUT -s 203.0.113.5 -j DROP. However, attackers often use many IPs, so consider fail2ban for dynamic blocking.

Q: Should I disable password authentication?
A: If you have SSH keys set up, yes. Disabling password auth eliminates the most common brute-force vector. Make sure you have a backup access method (e.g., console) before doing so.

Q: What if I find a successful login from an unknown IP?
A: Immediately disconnect the session (if any), change the password for that user, revoke any SSH keys, and check for backdoors. Review the entire auth log for other suspicious activity and consider a full security audit.

Related

• Second Free Mystery Game Epic Games Store Vampire Survivors?
• Best Long Swords in Monster Hunter Wilds
• Solid State Laser: Definition, Operation & Examples