{"id":407,"date":"2026-10-17T15:39:24","date_gmt":"2026-10-17T19:39:24","guid":{"rendered":"https:\/\/securebydefault.io\/blog\/?p=407"},"modified":"2026-10-17T15:42:18","modified_gmt":"2026-10-17T19:42:18","slug":"check-failed-ssh-logins-linux","status":"publish","type":"post","link":"https:\/\/securebydefault.io\/blog\/check-failed-ssh-logins-linux\/","title":{"rendered":"How to Check Failed SSH Login Attempts on Linux"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

You ran the command every tutorial tells you to run:<\/p>\n\n\n\n

grep \"Failed password\" \/var\/log\/auth.log<\/code><\/pre>\n\n\n\n
And nothing came back. No error, no results, just a fresh prompt.<\/p>\n\n\n\n
That’s an easy place to decide something is broken, or that your server is suspiciously quiet. Usually it’s neither. Linux can keep SSH logs in more than one place, and you may simply be looking in the wrong one.<\/p>\n\n\n\n
This guide covers where SSH logs live, how to read a failed-login line, how to count which addresses and usernames show up most, and how to check whether anything actually got in. It’s the reference version of a story I wrote up in the newsletter<\/a>, where I did this on a real server.<\/p>\n\n\n\n
Where SSH logs live on Linux<\/p>\n\n\n\n
\n\n\n\n
There are two main places to look.<\/p>\n\n\n\n
1. The systemd journal.<\/strong> Most modern distributions that use systemd keep logs in the journal, and you read them with journalctl<\/em><\/mark>. This is usually the first place to check.<\/p>\n\n\n\n
2. Log files such as<\/strong> \/var\/log\/auth.log<\/em><\/mark>.<\/strong> On Debian and Ubuntu, authentication messages are written to \/var\/log\/auth.log<\/mark> <\/em>by a logging service called rsyslog. On RHEL-family systems the equivalent file is usually \/var\/log\/secure<\/em><\/mark>.<\/p>\n\n\n\n
A system can have both, only one, or one that has only just started collecting. To see what you have:<\/p>\n\n\n\n
ls -l \/var\/log\/auth.log\nsystemctl status rsyslog<\/code><\/pre>\n\n\n\n
If the file doesn’t exist, or rsyslog isn’t running, the journal is where your history is. If the file exists but is small, it may only cover the time since rsyslog started.<\/p>\n\n\n\n
On my own server, auth.log<\/em><\/mark> existed but was tiny, because rsyslog had only recently started. The older records were all in the journal. On a stock Ubuntu install I tested afterward, the file existed with content, so this varies from machine to machine. That’s exactly why it’s worth checking rather than assuming.<\/p>\n\n\n\n
Find the SSH service name<\/p>\n\n\n\n
\n\n\n\n
The journal is organized by service. The SSH server’s name depends on the distribution:<\/p>\n\n\n\n
    \n
  • Debian and Ubuntu: ssh<\/em><\/mark><\/li>\n\n\n\n
  • Many others, including RHEL-family systems: sshd<\/em><\/mark><\/li>\n<\/ul>\n\n\n\n
    If you’re not sure, ask systemd:<\/p>\n\n\n\n
    systemctl list-units --type=service | grep -i ssh<\/code><\/pre>\n\n\n\n
    Then read that service’s logs:<\/p>\n\n\n\n
    journalctl -u ssh<\/code><\/pre>\n\n\n\n
    -u<\/mark><\/em> means “this unit,” which here is the SSH service. On a system that uses sshd<\/mark><\/em>, run journalctl -u sshd<\/mark><\/em>.<\/p>\n\n\n\n
    You may need permission<\/p>\n\n\n\n
    \n\n\n\n
    Reading the full journal requires sudo<\/mark><\/em>, or membership in the adm <\/mark><\/em>or systemd-journal<\/mark><\/em> group. Without it, a normal user gets this hint and no results:<\/p>\n\n\n\n