By the SNMP Monitoring team · Reviewed July 2026
Every team eventually feels the DIY temptation: why bother with SNMP when you can SSH into a box, run a command, and parse the output on a cron schedule? It works — for about a dozen hosts. Then the hidden costs surface: brittle parsing, sprawling credentials, and a security model that's wrong at the root. This page compares SNMP with SSH/agent-script monitoring fairly (scripts do have their place), but it doesn't pull the central punch: monitoring over SSH is insecure by design, because you're handing out a full remote-control channel just to read a number.
Parent: comparisons. Related: agentless external, OID allowlist.
The SSH/script approach
The DIY method is SSH in, run top/df/cat /proc/..., and parse the text. Its appeal and its problems:
- Flexible — you can collect literally anything a shell command can produce.
- No new protocol — reuses SSH you already run.
- Fragile — output formats change between OS versions, and your parser breaks silently.
- Credential-heavy — every monitored host needs shell access from the monitor.
- Unstandardised — each check is bespoke; nothing is uniform across vendors.
For a one-off, bespoke metric on a handful of machines, a script is fine. As a monitoring strategy across a fleet, it accumulates fragility and risk with every host you add.
The SNMP approach
SNMP inverts those trade-offs. It's standardised — the same OID means the same thing across vendors — and typed, so you get structured values, not text to scrape. Crucially, it can be strictly read-only and scoped to an OID allowlist, exposing only the metrics you choose and nothing else. No shell, no command execution, no parsing fragility:
snmpget -v2c -c public 10.0.0.20 hrProcessorLoad.1
HOST-RESOURCES-MIB::hrProcessorLoad.1 = INTEGER: 42
That one query returns a typed number over a read-only channel. The SSH equivalent is logging in with a shell account and parsing top output — more power, far more exposure, and a parser that breaks when the format shifts.
Comparison table
Side by side:
| Dimension | SNMP | SSH / scripts |
|---|---|---|
| Standardisation | Standardised OIDs | Bespoke per check |
| Data format | Typed values | Parsed text (fragile) |
| Privilege | Read-only, allowlisted | Full shell access |
| Attack surface | Only chosen OIDs | Command execution |
| Scale | Uniform across fleet | Scripts rot with growth |
| Overhead | Light (UDP) | Per-session SSH cost |
The privilege and attack-surface rows are the ones that should give any security-minded reader pause.
Security: SSH monitoring is insecure at its roots
Here's the argument that matters most, and it's a design-level one, not a tuning detail. SSH was built for interactive remote access and administration — a full remote-control channel with a shell and arbitrary command execution. Using it to monitor means granting exactly that channel just to read a metric. The credential that reads your CPU load can also run any command, install software, delete files, and pivot laterally to other systems. That's a fundamental purpose/privilege mismatch: you've provisioned a skeleton key to accomplish the job of a thermometer. You can narrow it with restricted shells and forced commands, but you're fighting the tool's nature the whole way, and one misconfiguration re-opens the whole channel.
SNMP read-only inverts this. With an OID allowlist, the credential exposes only the specific metrics you allow — data, with no shell, no command execution, and no path to anything else. A leaked SNMP read credential reveals a handful of health numbers; a leaked SSH monitoring credential is a foothold on the host. That difference in blast radius is the core security case, and it's why "just SSH in and check" is the wrong default for anything beyond a bespoke one-off.
Scale & maintenance
The operational case compounds the security one. As the fleet grows, scripts rot:
- An OS upgrade changes a command's output format, and a parser breaks — often silently.
- A new device class needs a whole new script, tested and maintained separately.
- Credential sprawl grows with every host that needs shell access.
- There's no uniformity — no single dashboard maps cleanly across bespoke checks.
SNMP, by contrast, is uniform: the same OIDs, the same tooling, the same read-only model across the whole estate, so adding a device is configuration, not code. Scripts scale in maintenance burden; SNMP scales in configuration.
External SNMP as the best of both
There's an option that keeps the "no software to deploy" appeal of scripts without the shell risk: external SNMP monitoring. An off-box poller reads a device's existing, hardened, read-only SNMP agent over an independent path — no scripts to install, no shell credentials to hand out, and a standardised, allowlisted data channel. You get the agentless convenience people reach for scripts to achieve, with SNMP's least-privilege security model instead of a remote-control channel. ostr.io provides exactly this — external, read-only SNMPv2c monitoring with an OID allowlist — as a concrete alternative to shell-script monitoring. More on the approach at agentless external and external monitoring.
Frequently asked questions
Should I use SNMP or SSH scripts for monitoring?
Use SNMP for anything beyond a bespoke one-off. Scripts are flexible for custom checks on a few hosts, but they require shell access, break when command output changes, and don't scale. SNMP is standardised, typed, and can be strictly read-only with an OID allowlist — safer and far more maintainable across a fleet. Reserve scripts for genuinely custom, small-scale needs.
Is SNMP safer than SSH-based monitoring?
Yes, fundamentally. SNMP read-only with an OID allowlist exposes only chosen metrics — data, with no shell. SSH monitoring grants a full remote-control channel: the credential that reads a metric can also run any command and pivot to other systems. That's a much larger blast radius if the credential leaks, which is why read-only SNMP is the least-privilege choice.
Is monitoring over SSH insecure?
At its roots, yes. SSH was designed for interactive remote access and administration, not read-only monitoring, so using it to monitor means provisioning a full command-execution channel just to read a number — a purpose/privilege mismatch. You can restrict it with forced commands, but you're working against the tool's nature. SNMP read-only exposes data without any shell.
Why are monitoring scripts fragile?
Because they parse human-readable command output, which isn't a stable contract. An OS upgrade or a locale change can alter the format of top, df, or /proc output, and the parser breaks — often silently, so you lose the metric without an obvious error. SNMP returns typed values against standardised OIDs, so there's no text to scrape and nothing to break on a format change.
Key takeaways
- SSH/script monitoring is flexible but fragile, needs shell access, and rots at scale.
- Monitoring over SSH is insecure by design — it grants a full remote-control channel to read a metric.
- SNMP is standardised, typed, and read-only with an OID allowlist — data, no shell.
- A leaked SNMP read credential reveals a few metrics; a leaked SSH one is a foothold.
- SNMP scales in configuration; scripts scale in maintenance burden.
- External SNMP (ostr.io) gives the agentless convenience without the shell risk — see agentless external.