---
type: Topic Hub
title: "SNMP Security & Session Monitoring — SSH Logins & Users"
description: "Watch logged-in users and SSH sessions over SNMP with the Host Resources hrSystemNumUsers OID, spot login spikes and alert from outside the network."
resource: "https://snmp-monitoring.com/sensors/security-sessions/"
tags: [sensors, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# SNMP Security & Session Monitoring — SSH Logins & Users

SNMP isn't a full security monitoring stack, and it would be dishonest to pretend otherwise — it won't parse auth logs, follow a `sudo` chain, or tell you *who* logged in. What it can do, cheaply and from outside the box, is give you a live count of interactive sessions: how many users are logged in right now. That single number is a surprisingly useful tripwire. A login count that jumps at 3 a.m., or that never returns to its baseline, is worth a look — and this category covers how to read it over SNMP and turn it into an alert.

## What SNMP can and can't see

The honest boundary matters here. SNMP's window into sessions is the Host Resources MIB (RFC 2790), which exposes `hrSystemNumUsers` at `1.3.6.1.2.1.25.1.5.0` — a scalar count of the users currently logged in, roughly what `who | wc -l` reports on a Unix host. That's the signal: a number, polled on a schedule, that you baseline and watch for anomalies.

What SNMP does *not* give you is identity or detail. There's no standard OID for usernames, source IPs, session start times, or authentication method. Those live in the system's auth logs (`/var/log/auth.log`, `journald`, `wtmp`), which are the right tool for forensic depth. Think of SNMP session monitoring as the smoke detector, not the investigation: it tells you *that* something changed and roughly *how much*, and it hands you the cue to go read the logs. Used that way — an always-on, low-cost count that fires an alert when it deviates — it earns its place.

## The session monitoring page

This category currently has one dedicated page, and it goes deep on the practicalities:

- [Monitor SSH Logins via SNMP](/sensors/security-sessions/ssh-sessions-logins.md) — reading `hrSystemNumUsers`, establishing a normal baseline, alerting on off-hours or unexpected session spikes, and understanding exactly where SNMP's visibility ends and log analysis has to take over.

## The OID at the center of it

| Object | OID | What it gives you |
|---|---|---|
| `hrSystemNumUsers` | `1.3.6.1.2.1.25.1.5.0` | Count of currently logged-in users (interactive sessions) |
| `hrSystemProcesses` | `1.3.6.1.2.1.25.1.6.0` | Count of running processes (useful context alongside sessions) |

Both are scalars ending in `.0`, so you fetch them with a single `snmpget` rather than a walk:

```
snmpget -v2c -c public <host> 1.3.6.1.2.1.25.1.5.0
```

The value is an integer. There's nothing to convert — the interpretation is all in the trend. Baseline what "normal" looks like for the host (a bastion with rotating admins behaves very differently from an app server nobody logs into), then alert on deviation from that baseline rather than any fixed number.

![Diagram of hrSystemNumUsers being polled from outside the network to track logged-in session count over time](https://snmp-monitoring.com/img/sensors/security-sessions.webp)

## Using the session count well

A raw count is only as good as the thresholds around it. A few habits make it trustworthy:

- **Baseline per host.** An app server that normally shows zero interactive users should alert on *one*. A shared jump host that averages three shouldn't. The meaningful signal is deviation from that host's own normal.
- **Weight the clock.** A login during a change window is expected; the same login at 3 a.m. on a box nobody touches is the one you want paged. Off-hours sessions deserve a louder alarm.
- **Correlate, don't conclude.** SNMP tells you the count moved. Pair the alert with a jump to the auth logs to answer who and from where — SNMP hands you the cue, the logs hold the story.
- **Poll from outside.** If a host is being tampered with, an on-box agent is the least trustworthy narrator of its own state. An independent external poller reading `hrSystemNumUsers` keeps reporting even when the box is under pressure.

## FAQ

**Can SNMP tell me who logged in?**
No. `hrSystemNumUsers` (`1.3.6.1.2.1.25.1.5.0`) is only a count of current sessions — there's no standard OID for usernames, source IPs, or auth method. Use it as a tripwire that tells you the count changed, then read the host's auth logs for identity and detail.

**Is SNMP a replacement for a SIEM or log analysis?**
No, and it isn't meant to be. SNMP gives you a cheap, always-on session count you can baseline and alert on from outside the network. Deep security analysis — log correlation, auth chains, intrusion detection — belongs to purpose-built tooling. The two complement each other.

**What's a good threshold for the login count?**
There's no universal number; it's per-host. Baseline the machine's normal — often zero for app servers, a small steady number for jump hosts — and alert on deviation, weighting off-hours sessions more heavily than ones during change windows.

**Why poll session count from outside the box?**
Because if a host is compromised or under load, its own agent is the least reliable witness to what's happening on it. An external poller reading `hrSystemNumUsers` independently keeps reporting the count even when the machine itself can't be trusted to raise the alarm.

## Conclusion

SNMP won't replace your logs or your SIEM, but `hrSystemNumUsers` (`1.3.6.1.2.1.25.1.5.0`) gives you something genuinely useful for almost no cost: a live, pollable count of interactive sessions you can baseline and alert on. Treat it as a tripwire — it tells you *that* the session count moved and hands you the cue to go read the auth logs for the *who* and *how*. Start with the [Monitor SSH Logins via SNMP](/sensors/security-sessions/ssh-sessions-logins.md) page for the full setup, then poll it from outside with [ostr.io Monitoring](https://ostr.io/service/monitoring) so an off-hours login spike reaches you by email and SMS even when the box itself can't be trusted to say so. The full menu lives in the [sensor & OID catalog](/sensors/index.md).