Securing SSH access is critical for any Linux server administrator. One of the most common attack vectors is brute-force attempts to log in via SSH, which often flood your logs with failed authentication messages. Knowing how to quickly identify and interpret these failed SSH login attempts can help you react faster to potential security threats and prevent unauthorized access. In this guide, I’ll walk you through practical, production-tested methods to find all failed SSH login attempts using built-in Linux tools, explain what the logs mean, and share how you can use this knowledge to improve your SSH security posture on Debian, Ubuntu, CentOS, RHEL, and other distributions.
Understanding Where SSH Logs Failed Login Attempts
Every attempt to connect to an SSH server—whether successful or failed—is recorded by the system logging daemon. Depending on your distribution and configuration, these logs are generally found in either /var/log/auth.log (common on Debian/Ubuntu) or /var/log/secure (typical on CentOS/RHEL). On newer systems running systemd, login attempts can also be viewed in the system journal with journalctl.
In my experience managing production servers, knowing exactly which log file to inspect is the first step. A big mistake I often see is admins querying the wrong log file or ignoring journalctl, which can hold real-time and historical log entries in a much more unified format, making incident response faster.
Finding Failed SSH Login Attempts Using Grep and Auth Logs
grep "Failed password" /var/log/auth.log Dec 14 12:03:21 server sshd[22853]: Failed password for invalid user admin from 192.168.1.45 port 59217 ssh2 Dec 14 12:05:44 server sshd[22910]: Failed password for root from 10.0.0.12 port 55344 ssh2 Dec 14 12:08:07 server sshd[22987]: Failed password for user1 from 203.0.113.99 port 42218 ssh2
This command filters the authentication log and displays all entries associated with failed password attempts. The term “Failed password” is what the SSH daemon generally logs when a password-based login attempt fails. You’ll see the timestamp, process ID, username, remote IP, and port used by the attacker or user who failed to authenticate.
On Debian and Ubuntu systems, this is the quickest way I use for a quick check, especially after noticing suspicious activity or performance impacts. Running it as root or with sudo is critical since auth logs usually require elevated privileges for access.
Viewing Additional Failure Messages with Egrep
egrep "Failed|Failure" /var/log/auth.log Dec 14 12:03:21 server sshd[22853]: Failed password for invalid user admin from 192.168.1.45 port 59217 ssh2 Dec 14 12:06:28 server sshd[22860]: Authentication failure for root from 10.0.0.50 Dec 14 12:08:07 server sshd[22987]: Failed password for user1 from 203.0.113.99 port 42218 ssh2
Using egrep with multiple patterns expands your filtering to catch more types of authentication failures beyond just “Failed password.” Depending on your SSH configuration and PAM modules, other failure messages might show up as “Authentication failure” or variations thereof. This is particularly useful if you’re troubleshooting more exotic login issues or auditing your security logs thoroughly.
Checking Failed SSH Attempts on CentOS/RHEL Servers
egrep "Failed|Failure" /var/log/secure Dec 14 14:22:11 centosserver sshd[12345]: Failed password for invalid user test from 198.51.100.10 port 51231 ssh2 Dec 14 14:23:44 centosserver sshd[12401]: Authentication failure for root from 198.51.100.15 Dec 14 14:25:06 centosserver sshd[12450]: Failed password for admin from 192.0.2.55 port 49322 ssh2
Unlike Debian-based distributions, CentOS and RHEL keep their authentication logs in /var/log/secure. Otherwise, the commands to sift through the logs remain practically the same. For any sysadmin managing varied Linux distributions, this distinction is essential, or you risk missing critical login failure data during audits or incident response activities.
Aggregating and Counting Failed SSH Attempts by IP Address
grep "Failed password" /var/log/auth.log | awk '{print $11}' | uniq -c | sort -nr
125 192.168.1.45
47 203.0.113.99
12 10.0.0.12
8 198.51.100.10 This one is a practical trick I use when hunting down the most persistent attackers. The command extracts the 11th field from the log lines—usually the IP address of the failed login attempt—then counts occurrences and sorts them descending by frequency. This allows you to quickly spot the worst offenders who might warrant immediate firewall blocking or fail2ban action.
On busy production environments, this kind of aggregation saves hours of manual log analysis and lets you respond swiftly to brute-force attacks or persistent unauthorized login attempts.
Using Journalctl for Failed SSH Login Detection on Systemd Systems
journalctl _SYSTEMD_UNIT=ssh.service | egrep "Failed|Failure" Apr 24 09:13:44 myserver sshd[3521]: Failed password for invalid user guest from 172.16.254.1 port 58524 ssh2 Apr 24 09:14:05 myserver sshd[3533]: Authentication failure for root from 192.168.10.100
For servers running systemd, journalctl is an even more powerful tool, aggregating logs from multiple sources with advanced filtering. Filtering based on the SSH service unit lets you limit results strictly to SSH-related events, making investigations much more focused.
On CentOS/RHEL, the service name changes slightly:
journalctl _SYSTEMD_UNIT=sshd.service | grep "failure" Apr 24 15:45:21 centos sshd[7012]: Failed password for root from 203.0.113.45 port 52810 ssh2 Apr 24 15:46:10 centos sshd[7020]: Failed password for admin from 198.51.100.22 port 53532 ssh2
This approach is especially valuable for live monitoring or retrospective incident analysis. In my day-to-day work, I combine journalctl with tools like tail -f or process the output in scripts to automate alerts whenever suspicious failed login patterns appear.
Practical Recommendations After Identifying Failed SSH Logins
Once you’ve identified the IP addresses that are hammering your SSH server with failed login attempts, it’s crucial to take quick action to mitigate potential compromise risk. One immediate step is to block these malicious IPs using your firewall—be it iptables, firewalld, or nftables. For a more scalable and automated approach, deploying tools like fail2ban is highly recommended. Fail2ban reads log files, dynamically bans IPs that exceed a failure threshold, and dramatically reduces the noise from brute-force attacks.
Another best practice I swear by is regularly reviewing SSH configuration to disable root login, use key-based authentication, and limit allowed users. Proper log monitoring combined with proactive defense strategies can save you from costly breaches and downtime caused by attackers.
Conclusion
Regularly auditing failed SSH login attempts is an essential task in Linux server administration and security management. Using commands like grep on auth logs or leveraging the powerful journalctl tool on systemd-based systems can help you quickly spot brute-force attempts or suspicious access patterns. In my experience, correlating IP frequency and automating response mechanisms like fail2ban is a game changer for maintaining hardened, resilient servers. Always remember to customize your monitoring routines based on your environment and keep your SSH configs tight. After all, SSH is your frontline remote access gateway, and monitoring its health and threats is a foundational sysadmin responsibility.
