---
type: Article
title: "Monitor SSH Logins via SNMP"
description: "One SNMP counter reports how many user sessions are open right now. On a headless Linux box that's a live login signal — an unexpected jump is a warning."
resource: "https://snmp-monitoring.com/sensors/security-sessions/ssh-sessions-logins/"
tags: [sensors, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# Monitor SSH Logins via SNMP

If someone logs into your server who shouldn't, you want to know in minutes — not when you read the auth log next week. One of the simplest ways to monitor SSH logins is a single SNMP counter that tells you how many user sessions are open right now. On a headless Linux box, where practically every interactive session arrives over SSH, that number is a live indicator of who's connected. Watch it, learn its normal shape, and an unexpected jump becomes an early warning of an unauthorized login. This page covers the exact OID, how it behaves, how to read it, and how to turn it into fraud login detection that fires even when the box itself has been compromised.

## What it means to monitor SSH logins, and why it matters

To monitor SSH logins is to keep a running count of the interactive user sessions on a machine and to notice when that count changes unexpectedly. SNMP doesn't give you usernames or source IPs — it gives you a number: how many users are currently logged in. That sounds crude, but it's remarkably useful, because on a typical production server the baseline is boring and stable. Zero most of the time. One while you're working. That predictability is exactly what makes a deviation meaningful.

Here's the operational value. A server that normally sits at zero interactive sessions suddenly showing two at 3 a.m. is a fact worth investigating. A count that climbs and stays elevated can mean a session someone forgot to close — or an attacker who let themselves in. Because the metric is a live gauge rather than a log you have to parse, you can alert on it in near real time instead of doing forensics after the fact.

The symptoms it surfaces are the ones that matter for security. Unexpected sessions outside working hours. A session count that doesn't drop back to baseline when it should. A spike that lines up with a brute-force attempt you're seeing elsewhere. None of that requires shipping logs off the box or running a heavyweight agent — the session count is already published over SNMP. That's the appeal: fraud login detection cheap enough to run on every server you own, watching the one number that quietly says *someone is here*.

![Diagram of an external SNMP monitor reading hrSystemNumUsers from a server's agent to detect unexpected SSH login sessions](https://snmp-monitoring.com/img/sensors/ssh-logins-poll.webp)

## The OID: 1.3.6.1.2.1.25.1.5.0

The value you want is `1.3.6.1.2.1.25.1.5.0` — `hrSystemNumUsers` in the Host Resources MIB (RFC 2790). It's a scalar, not a table: a single `Gauge32` that reports the number of user sessions the host currently considers active. Because it's a gauge, it goes up and down in real time as people log in and out — unlike a counter, it always reflects the present state.

| Property | Value |
|---|---|
| OID | `1.3.6.1.2.1.25.1.5.0` |
| Object name | `hrSystemNumUsers` |
| MIB / standard | Host Resources MIB (RFC 2790) |
| Type | `Gauge32` (count of sessions) |
| Behaviour | Live value — rises and falls with active sessions |

One honest caveat, because accuracy matters here. `hrSystemNumUsers` counts *all* interactive user sessions the operating system tracks, not SSH connections specifically. On a headless server that's a distinction without much difference — there's no console user, no desktop session, so essentially every session is an SSH one, and the number is an excellent proxy for SSH activity. On a machine with local logins or a GUI, remember that those sessions are counted too. Read the number for what it is: total logged-in users, which on a remote-managed box means your SSH sessions. That's what lets you detect ssh login snmp changes without any extra tooling — the standard agent already exposes it.

## How to query it

Any Net-SNMP client reads this in one call. The examples assume an SNMPv2c agent with a read-only community; if you haven't set that up, the [snmpd.conf guide](/setup/snmpd-conf.md) covers it.

1. **Read the current session count** directly — it's a scalar, so `snmpget` is all you need:
   ```bash
   snmpget -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.1.5.0
   ```
   Sample output:
   ```
   HOST-RESOURCES-MIB::hrSystemNumUsers.0 = Gauge32: 1
   ```
2. **Walk the branch** if you want the surrounding system values (uptime, processes) alongside it:
   ```bash
   snmpwalk -v2c -c public 10.0.0.5 1.3.6.1.2.1.25.1
   ```
3. **Force numeric output** if the Host Resources MIB isn't installed locally:
   ```bash
   snmpget -v2c -c public -On 10.0.0.5 1.3.6.1.2.1.25.1.5.0
   ```

Reading it once gives you a snapshot. The value of monitoring comes from reading it *repeatedly* and comparing against what's normal for that host. Poll it on a steady cadence, keep the history, and you can alert on two things: an absolute count above a threshold you'd never expect, and a change from baseline at a time when nobody should be logging in. If the query hangs rather than returning, that's the usual trio — wrong community, wrong port, or a firewall — not the OID. An error saying the object doesn't exist means it isn't in the agent's view; add it to your [OID allowlist](/setup/oid-allowlist.md).

## Normal vs alarming values & thresholds

There's no universal "safe" session count — it depends entirely on how the server is used — so the trick is to baseline each host and alert on the departure. A few patterns hold up across most machines:

- **0 sessions, sustained** — normal for an unattended production server between maintenance windows.
- **1–2 sessions during working hours** — expected while an admin is connected; benign.
- **Any sessions outside your maintenance windows** — worth a look; a login at an odd hour is the classic fraud signal.
- **A count above your known team size** — alarming; more sessions than people who should have access.
- **A session count stuck high and not returning to baseline** — investigate; it may be an orphaned session or an intruder holding a shell open.

Two habits make SSH login alerting trustworthy rather than noisy. First, alert on deviation from each host's baseline, not on a fixed number — a bastion host that always has three sessions and a database node that should always have zero need different rules. Second, weight the *time* of the change heavily: the same jump from zero to one is unremarkable at 2 p.m. and alarming at 2 a.m. For a full playbook that ties this together, see the guide on [how to detect fraudulent SSH logins](/guides/detect-fraud-ssh-logins.md).

## Alerting on this metric externally

Here's the uncomfortable part of watching logins from the server itself: if the login you're worried about is an attacker, the first thing a capable one does is silence the local alerting. Kill the agent, edit the config, tamper with the logs — a session count watched only from inside the compromised box can be muted by the very person it was meant to catch. On-host monitoring trusts the host, and that trust is exactly what's in question during an intrusion.

Polling from outside sidesteps that. It's the idea behind [double durability](/monitoring/double-durability.md): an independent watcher reads `hrSystemNumUsers` from beyond the server, keeps its own history, and applies its own thresholds — on hardware the intruder can't touch. Because SNMP is a pull protocol, the external side just reads `1.3.6.1.2.1.25.1.5.0` on its own schedule, so even a session that never shows up in a tampered local log still moves a number an outside observer is watching.

![Chart of SSH session count over 24 hours from hrSystemNumUsers with an unexpected overnight spike crossing a fraud-detection threshold](https://snmp-monitoring.com/img/sensors/ssh-logins-chart.webp)


## FAQ

**Does `hrSystemNumUsers` count only SSH logins?**
Not strictly — it counts all interactive user sessions the OS tracks. On a headless server with no console or GUI users, that's effectively all SSH, so it's an excellent proxy. On a machine with local or desktop logins, remember those are included in the total.

**Can I see *who* logged in over SNMP?**
No. `hrSystemNumUsers` is just a count — no usernames, no source IPs. Use it as the real-time trigger, then pull identity from the server's own auth logs once an unexpected change alerts you. The [fraud SSH login guide](/guides/detect-fraud-ssh-logins.md) walks through that workflow.

**How do I turn a session count into fraud login detection?**
Baseline the host's normal count, then alert on deviations — especially any increase outside your maintenance windows or a total above your team size. The time of the change matters as much as the number.

**Which SNMP version should I use for this?**
Because this is a security signal, prefer SNMPv3 where you can, for authenticated and encrypted polling. SNMPv2c works for read-only access on a trusted network, but its community string travels in clear text.

## Conclusion

To monitor SSH logins over SNMP, you watch one scalar — `hrSystemNumUsers` at `1.3.6.1.2.1.25.1.5.0` — a live gauge of how many user sessions are open, which on a headless server means your SSH connections. It won't name the user, but as a real-time trigger it's hard to beat: baseline the host, alert on the unexpected, and pay attention to *when* the count moves. Publish it in your [snmpd.conf](/setup/snmpd-conf.md), confirm it clears your [OID allowlist](/setup/oid-allowlist.md), pair it with the [fraud SSH login guide](/guides/detect-fraud-ssh-logins.md), and browse the rest of the [sensor & OID catalog](/sensors/index.md) or the [full OID list](/sensors/all.md).

Monitor SSH logins from outside your network with [ostr.io Monitoring](https://ostr.io/service/monitoring) — independent, agentless checks with real-time email and SMS alerts, so an unexpected login reaches you even when an intruder has silenced everything on the box itself.