---
type: Article
title: "Detect Fraudulent SSH Logins"
description: "Spot an unauthorized SSH login over SNMP without touching a log file: poll the active-session count from outside and alert when it jumps at 3 a.m."
resource: "https://snmp-monitoring.com/guides/detect-fraud-ssh-logins/"
tags: [guides, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# Detect Fraudulent SSH Logins

You can detect unauthorized SSH login activity over SNMP without touching a single log file. The trick is a small, standard counter — the number of active user sessions the server reports — polled from outside the box. When that count jumps at 3 a.m., or climbs while every legitimate admin is asleep, you've got your ssh intrusion alert. This guide covers the exact OID, the command to read it, and why watching from outside the server is the part that actually protects you.

## The problem

SSH is the front door to your infrastructure, and attackers know it. Credential-stuffing bots hammer port 22 around the clock; a leaked key or a reused password is all it takes for one of them to walk in. The break-in itself is often silent. No crash, no error — just a new session, quietly opened, doing whatever it likes with the access it stole.

The conventional answer is to comb `auth.log` or lean on `fail2ban`. Both are fine, and both share a weakness: they run *on the compromised host*. An intruder with root can edit the logs, kill the log shipper, or simply disable the very tool watching for them. Your tripwire is sitting inside the room with the burglar.

There's a subtler gap, too. Failed-login tooling is loud about *attempts* and quiet about *success*. The break-ins that matter are the ones that worked on the first try — a valid key, no failures to count. You need a signal that reflects reality: is someone logged in right now who shouldn't be?

![Diagram showing an external SNMP poller reading the hrSystemNumUsers session count to raise an ssh intrusion alert on an unauthorized login](https://snmp-monitoring.com/img/guides/detect-unauthorized-ssh-login.webp)

## Solution overview

SNMP gives you exactly that signal, and it does it from a distance. The Host Resources MIB (RFC 2790) exposes `hrSystemNumUsers` at `1.3.6.1.2.1.25.1.5.0` — the number of user sessions the host currently reports as logged in. It's a plain gauge. Poll it, and you know how many people are on the machine.

The detection logic is refreshingly simple. You learn what *normal* looks like — maybe your team never has more than two concurrent sessions, and never outside working hours — and you alert on the departure. A handful of deviations make a reliable ssh intrusion alert:

- The session count climbs above your known ceiling.
- Any session at all appears during hours nobody on your team ever works.
- A reboot or a new process shows up that you didn't initiate, right after a login.

None of those needs deep log analysis. Each is a plain number moving in a way it shouldn't, and that's what makes it cheap to watch continuously.

Because it's read over SNMP, the poll comes from a separate machine. The attacker on the server can't see it happening and can't tamper with a log that was never the source. Even better, an external checker keeps score right through an outage or a wipe — the reading, or its absence, still tells you something.

## Step-by-step

Here's how to detect unauthorized SSH login attempts turning into sessions, end to end.

1. **Expose the session counter.** On the server, add `1.3.6.1.2.1.25.1.5.0` to your SNMP agent's allowlisted view in `/etc/snmp/snmpd.conf`. Keep it read-only and v2c. The [OID allowlist guide](/setup/oid-allowlist.md) shows the exact `view` line; the [snmpd.conf setup](/setup/snmpd-conf.md) covers the community and access lines.
2. **Restart and confirm the agent.** `service snmpd restart`, then `service snmpd status` to be sure it came back up.
3. **Read the count from your poller.** From an external machine, grab the current session total:
   ```bash
   snmpget -v2c -c public 203.0.113.10 1.3.6.1.2.1.25.1.5.0
   ```
   You'll get a single INTEGER — that's how many sessions are live right now.
4. **Establish a baseline.** Poll it over a normal week. Note the usual ceiling and the hours sessions actually appear. This is the line everything else measures against.
5. **Define the alert rule.** Two conditions catch most fraud: the count exceeds your known maximum, or *any* session exists during a window when nobody should be logged in. Off-hours access is often the louder tell.
6. **Poll on a tight cadence and alert externally.** Check every few minutes from outside the network so a real intrusion surfaces fast — and so the polling survives if the box is tampered with.

Pair this with key-only auth, a moved SSH port, and `fail2ban` on the host. SNMP session monitoring isn't a replacement for hardening; it's the independent watcher that notices when the hardening was beaten.

## Configuration / example

The whole detection hangs on one object, plus a couple of neighbours worth polling alongside it.

| Signal | OID | Object | Why it helps |
|---|---|---|---|
| Logged-in sessions | `1.3.6.1.2.1.25.1.5.0` | hrSystemNumUsers | The core intrusion signal — sudden or off-hours jumps |
| System uptime | `1.3.6.1.2.1.25.1.1.0` | hrSystemUptime | A reboot you didn't schedule is its own red flag |
| Running processes | `1.3.6.1.2.1.25.4.2.1.7` | hrSWRunStatus | Unexpected new processes after a login spike |

A quick shell loop turns the counter into a crude alarm you can test with:

```bash
# Poll every 60s; shout if sessions exceed the expected max of 2
while true; do
  users=$(snmpget -v2c -c public -Ovq 203.0.113.10 1.3.6.1.2.1.25.1.5.0)
  [ "$users" -gt 2 ] && echo "ALERT: $users SSH sessions active"
  sleep 60
done
```

The `-Ovq` flags strip the output down to the bare value so the comparison is clean. In production you'd hand this job to a real poller rather than a `while` loop — the logic, though, is exactly this.

## External alerting

A tamper-proof signal is only worth as much as the alert it triggers, and the alert has the same weak spot as everything else on the host: if it originates *on* the server, a capable intruder can strangle it. Kill the mailer, block the outbound port, and your ssh intrusion alert dies in the room where it was born.

Polling `hrSystemNumUsers` from outside removes that leverage. The checker sits on independent hardware, reads the count on its own schedule, and sends the alert from a place the attacker never touched. That's the heart of [double durability](/monitoring/double-durability.md) — the watcher and the watched don't share a fate, so compromising one doesn't blind the other.

Detect unauthorized SSH login activity from outside your network with [ostr.io Monitoring](https://ostr.io/service/monitoring). It polls your SNMP endpoint independently and sends real-time email and SMS alerts on SSH logins the moment the session count moves — reaching you even if the intruder has already muzzled everything running on the box.

![Timeline chart of active SSH session count with a normal daytime baseline and a flagged off-hours spike marking a fraudulent login](https://snmp-monitoring.com/img/guides/ssh-session-spike.webp)


## FAQ

**Which OID do I poll to detect unauthorized SSH login sessions?**
`1.3.6.1.2.1.25.1.5.0` — hrSystemNumUsers in the Host Resources MIB (RFC 2790). It returns the count of user sessions the host currently reports as logged in. A jump above your baseline, or any session at an unexpected hour, is your signal.

**Does the session count separate SSH from console logins?**
No — `hrSystemNumUsers` counts user sessions broadly, not SSH specifically. On a headless server, though, essentially every interactive session *is* SSH, so the count tracks it closely. Treat it as "someone is logged in," then confirm the source in the auth logs.

**Can an attacker hide from this?**
They can tamper with on-host logs, but not easily with a reading a remote poller already took. That's the point of watching from outside — the session count reaches an external checker before anyone on the box can rewrite history.

**Is this a replacement for fail2ban?**
No, they're complementary. `fail2ban` blocks brute-force *attempts* at the door; SNMP session monitoring catches a login that *succeeded* and produces an independent, off-host ssh intrusion alert.

## Conclusion

To detect unauthorized SSH login activity with SNMP, expose `hrSystemNumUsers` at `1.3.6.1.2.1.25.1.5.0`, baseline your normal session count and hours, and alert on any departure from it — a jump in sessions, or access when nobody should be online. Poll it from outside the server and the whole scheme becomes tamper-resistant, because the ssh intrusion alert fires from hardware the attacker never reached. Simple counter, independent watcher, real protection. For related use-cases, browse the full [SNMP monitoring guides](/guides/index.md) or return to the [knowledge base home](/index.md).