1001Ferramentas
🛡️ Security

SSH auth.log Analyzer

Analyzes SSH auth.log files: failures per IP, targeted users, accepted logins, attack peaks and ready-to-copy block lists.

Everything runs inside your browser. The log you paste is never uploaded — this page makes no network request while analyzing.

How the counting works

Only sshd authentication events are counted: Failed password, Accepted password or publickey, Invalid user and Connection closed at preauth. A line such as "message repeated 4 times: [ Failed password for root ... ]" is expanded into four failures, which is why the failure total can be larger than the number of lines you pasted.

The syslog stamp "Jul 25 03:14:15" carries no year, so the chronological order used here is the order of the lines in the file, which is how syslog writes them. An IP that shows both failures and an accepted login is highlighted: on a server exposed to the internet that pattern is the signature of a password guessed after a long brute-force run.

See who keeps knocking on your server

A server with port 22 open collects thousands of login attempts a day, and auth.log grows until it is far too long to read line by line. Paste the contents here and the page pulls out what matters: how many failures there were, which addresses they came from, which usernames the attackers guessed and whether anyone actually got in. The text never leaves your browser tab.

The count treats a message repeated 4 times line as four failures rather than one. That changes the final number quite a lot, since a brute-force burst of 200 attempts usually takes up half a dozen lines in the file. The syslog stamp, in the form Jul 25 03:14:15, carries no year, so the chronological order used here is the order of the lines themselves, which is how syslog writes them.

The signal worth hunting for is not the volume of failures, it is the coincidence. An IP that shows 400 failures and, somewhere among them, an Accepted password is highlighted in red in the table: the password fell. Blocking the address at that point solves little. The next step is rotating the credential, reviewing authorized_keys for that account and checking what ran after that timestamp.

Frequently asked questions

Do I need fail2ban installed to use this?
No. The parsing runs on whatever text you paste, whether that is /var/log/auth.log on Debian and Ubuntu, /var/log/secure on RHEL or the output of journalctl -u ssh. The result is what helps you decide what to feed fail2ban or the firewall afterwards, based on what the log actually shows.
Why is the failure total larger than the number of lines?
Because syslog collapses repeats. When the same message recurs, it writes a single line such as message repeated 12 times instead of twelve identical lines, and the analysis expands that number back out. Without it, a persistent attack would look far smaller than it really was.
Can I apply the block list straight on the server?
You can, but review it first. A legitimate IP that mistyped the password five times lands in the list exactly like a bot, and blocking your own office address with iptables usually costs a trip to the physical console. Only tokens shaped like an IP address make it into the list, so nothing from the log becomes a command argument.

Related Tools