SNMP Security & Session Monitoring — SSH Logins & Users

Q: 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.

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 — 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

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.

Frequently asked questions

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 page for the full setup, then poll it from outside with ostr.io 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.