How do I alert on login spikes?

Baseline normal session counts and alert when the count remains above threshold or jumps sharply for several poll intervals.

How to Monitor SSH / Login Sessions via SNMP

By the SNMP Monitoring team · Reviewed July 2026

Active login sessions over SNMP are a blunt instrument—and still useful. The standard object is a count, not a guest list. You won’t get usernames or source IPs from HOST-RESOURCES. You will get “how many sessions are live right now?” which is enough for capacity spikes, jump-host abuse patterns, and “why is this box sad?” correlation.

Twin: ssh-sessions sensors. Parent: server. Security depth: best practices.

What SNMP exposes

You get:

A single integer: active user sessions
Cheap to poll
Works when implemented on the agent

You don’t get:

Who logged in
From where
SSH vs console vs other session types broken out (unless the agent’s definition is documented specially—assume aggregate)
Auth success/failure events (use logs/traps elsewhere)

If someone promises “SNMP shows the SSH username,” they’re not talking about hrSystemNumUsers.

The OID: hrSystemNumUsers

hrSystemNumUsers = 1.3.6.1.2.1.25.1.5.0 — number of active user sessions on the host.

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.1.5.0

HOST-RESOURCES-MIB::hrSystemNumUsers.0 = Gauge32: 3

Three sessions. That’s the whole telegram. Graph it. Baseline it. Alert on weirdness.

snmpget output showing the active session count (hrSystemNumUsers)

Use cases

Numbered scenarios that actually happen:

Jump host capacity — session count climbs all day; plan bigger boxes or fix idle timeouts.
Anomaly / security signal — 0→40 sessions at 03:10 without a change window; investigate with auth logs, not SNMP alone.
Correlation — high sessions + high load + high process count = training class or incident.
“Ghost” load — count stays high when CPU is idle: idle SSH sessions; tighten ClientAlive settings.
Post-incident forensics — timeline of session count beside deploy markers.

None of these replace SIEM. They add a cheap numeric channel.

Limits and how to fill them

Need	SNMP count?	Better source
How many sessions?	Yes	hrSystemNumUsers
Who / from where?	No	auth.log, journal, sshd, IdP
Brute force?	No	fail2ban logs, IDS, sshd
Session content	No	Never via SNMP—don’t want that

Pair SNMP with logs. Security controls: best practices. Process sprawl nearby: processes.

Reference

Leaf notes and wording: sensors/ssh-sessions. Alerts: alerts.

Alert ideas:

Warn if sessions > N for M minutes on a host that should be quiet
Crit if sessions explode (×5 baseline) suddenly
Don’t alert on zero unless the host should always have a management session (rarely)

External monitoring

Off-box polling of session count helps when you want an independent view of “is anyone on this box?” alongside uptime/CPU. ostr.io can read SSH/login sessions via 1.3.6.1.2.1.25.1.5.0 externally—still only a count. Allowlist that OID; don’t open the whole MIB. See external.

One CTA on this page.

Baseline method

Poll every 1–5 minutes for a quiet week.
Note p50/p95 session counts per host class.
Set warn above p95 with duration.
Revisit after onboarding a 20-person ops team (baselines move).

Failure modes

Expecting usernames from this OID
Alerting on developer workstations with chaotic sessions
Ignoring that some agents count differently (test!)
Using sessions as sole security control

Honest scope statement

Put this in the runbook: “SNMP session metric = count only. Identity investigation = logs.” Stops ticket ping-pong.

Also note: container hosts and jump hosts behave differently—templates per role, not one global threshold.

Glossary: glossary.

Example thresholds by role

Role	Typical baseline	Warn idea
Quiet app VM	0–2	>5 for 15m
Shared jump host	5–30	>p95 or sudden ×3
Build agent	bursty	use wide windows

Copy-paste thresholds without role context will either never fire or always fire. Label templates sessions_jump vs sessions_app.

Investigation path when the count spikes

Note time range from the graph.
Pull auth logs for that window (sshd, VPN, bastion).
Check for shared break-glass accounts.
Check for automation (Ansible, backup) that opens many sessions.
Only then hunt malware—most spikes are humans or scripts.

SNMP gave the “when.” Logs give the “who.” Keep that division of labor explicit in the ticket template so junior on-call doesn’t stall waiting for SNMP to print usernames it will never print.

High sessions + high process count + high CPU: interactive load or fork storm. High sessions + idle CPU: idle SSH clutter. High sessions + disk filling on /var: logging or session spam. Cross-link processes, disk, CPU.

What “active user sessions” means in practice

HOST-RESOURCES defines a host-level session count. On a typical Linux box that often tracks logged-in users in the utmp sense—not every SSH TCP handshake that failed auth, and not necessarily every multiplexed connection the way you imagine. Verify with a controlled test: open three SSH logins, snmpget the OID, close two, snmpget again. If the number doesn’t track, read your agent docs before building a security program on it.

Windows SNMP session semantics can differ—test on Windows the same way before cloning Linux thresholds.

Automation that opens many sessions

CI runners, config management, and backup tools can create session spikes that look like attacks. Tag those hosts with wider thresholds or suppress during known job windows. Otherwise you’ll page on every Ansible fan-out. Conversely, a spike on a PCI jump host with no automation window is worth waking someone.

Single metric, clear contract

Put in the dashboard footer: Metric: hrSystemNumUsers (1.3.6.1.2.1.25.1.5.0) — count only. Reduces “SNMP is broken, it won’t show the user” tickets by half.

Ship a one-line runbook link from the alert: “Spike in sessions → check auth logs for time T; SNMP will not list usernames.” That single sentence is worth more than another paragraph of theory. Re-test the OID after sshd or agent upgrades; session accounting is boring until it drifts from reality and your baselines go nonsense.

For shared bastions, consider separate warn thresholds for business hours vs nights if your NMS supports calendars—humans login on a schedule, attackers less so.

OID 1.3.6.1.2.1.25.1.5.0 = session count.
Capacity + anomaly signal; not identity.
Pair with logs and security tooling.
Twin: sensors/ssh-sessions.
External count: ostr.io.