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.

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.

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 covers it.

1. Read the current session count directly — it's a scalar, so snmpget is all you need:

   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:

   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:

   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.

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.

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