How to Monitor SSH Logins in Real-Time (Without Reading auth.log All Day)

Somewhere on the internet, right now, a botnet is guessing passwords on your SSH port. That is not speculation — any host with port 22 exposed sees hundreds of login attempts per day. Most fail. Occasionally, one does not.

The question is not whether someone is knocking on your SSH door. It is whether you would notice the moment the knock succeeds. This guide covers what SSH login monitoring actually needs to catch, and how to get alerts in minutes instead of discovering a breach in a log review next month.

What auth.log already knows

Every SSH event — successful logins, failed passwords, key rejections, disconnects — lands in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL family), plus the systemd journal. The data is all there. The problem is volume: a busy host generates thousands of failed attempts daily, and the signal hides in the noise.

The events that actually matter:

• Successful logins from unknown sources — one Accepted line from an IP that has never logged in before is worth more than ten thousand failures.
• Failed-login bursts — a spike in failures from a single source signals an active brute-force run, not background scanning.
• New credentials appearing — a new authorized_keys entry or a new user account is persistence, not exploration.
• Logins at unusual times — a 4 AM login on a host nobody touches at night deserves a second look.

Reading auth.log line by line catches none of this reliably. The volume guarantees you will skim past the one line that matters.

What an internal agent can see

An agent on the host turns the log stream into events:

• Failed SSH attempts — parsed continuously, grouped by source, emitted when thresholds are crossed rather than on every line.
• Successful logins — every Accepted event becomes a notification candidate with user, source IP and method (password vs. key).
• Credential changes — file-integrity watching on authorized_keys files and /etc/passwd catches persistence attempts even when the login itself looked clean.
• New user accounts — account creation events surface immediately, whether they came through SSH, a compromised package, or a cloud-init change.

The difference from a plain log grep: the agent tracks state. It knows which source IPs are new, which users are expected, and when an event breaks the pattern — that context is what separates "interesting" from "noisy".

Wiring it to alerts

With Uptriva the path is short:

1. Install the agent on the host — it starts reporting SSH events and file-integrity changes out of the box.
2. Create an event rule: alert on every successful SSH login, or only on logins from unrecognized sources. Failed-login bursts get their own threshold rule.
3. Watch authorized_keys and /etc/passwd via the file-integrity detector — a modified keys file alerts even if the login event itself was missed.
4. Route through escalation chains — a security event can page differently than an uptime event: Slack for failed bursts, SMS or a call for successful logins and credential changes.

In practice this means: a brute-force run shows up as a Slack message, and the first successful unusual login lands on your phone before the attacker has opened a second shell.

The honest caveat

Log-based detection is only as good as the log. An attacker with root can scrub auth.log — which is exactly why the file-integrity and account-creation signals matter as a second layer. And SSH monitoring tells you about the door; it does not watch what happens after a legitimate login. For the full picture, pair it with process, port and log-anomaly detection on the same host.

Uptriva's agent reports SSH login events, failed-attempt bursts, file-integrity changes and new user accounts out of the box — wired into the same escalation chains as your uptime monitors: agent docs.