Install snmpd on Ubuntu/Debian

To install snmpd on Ubuntu is genuinely a one-line job, and yet the number of servers that end up silent afterwards is depressing. The package installs, the service starts, and then nothing answers — because the daemon shipped bound to localhost and switched half-off. This guide gets you past that. It covers the exact apt-get install snmpd command, the companion packages that make the output readable, the /etc/default/snmpd toggle that actually turns the agent on, and the first walk that proves it's alive. The deeper access rules belong to their own page; here the goal is a running agent, cleanly installed, ready to configure.

Prerequisites

Nothing exotic is needed to install snmpd on Debian or Ubuntu, but check these first:

• Root or sudo. You're installing a package and editing files under /etc/.
• A supported release — any currently maintained Ubuntu LTS or Debian stable ships Net-SNMP in its repositories, so no third-party APT source is required.
• Working package metadata. Run apt-get update recently, or the install may pull a stale candidate.
• Outbound access to the mirrors during install; after that the agent needs no internet at all.
• A second machine with the Net-SNMP client tools to test from, since you should never verify from localhost.

You do not need to pick your community string or OID list yet. Get the software on disk and answering first; harden it after.

Step-by-step

The whole install is a handful of commands. Run them in order.

1. Refresh the package index so APT sees current versions:

   sudo apt-get update
   

2. Run the apt-get install snmpd command. Pull the daemon plus the client tools in one go:

   sudo apt-get install -y snmpd snmp
   

   The snmpd package is the agent (the service that answers queries). The snmp package gives you snmpwalk, snmpget, and friends for testing.
3. Add the MIB names so output reads as hrSystemUptime rather than a raw number string. This one is optional but worth it:

   sudo apt-get install -y snmp-mibs-downloader
   

   On Debian and Ubuntu the MIBs are disabled by default for licensing reasons; installing this package and enabling them makes snmpwalk print human-friendly object names.
4. Enable the daemon. This is the step everyone forgets. Edit /etc/default/snmpd:

   sudo nano /etc/default/snmpd
   

   and set:

   SNMPDRUN=yes
   TRAPDRUN=no
   

5. Restart and enable at boot:

   sudo service snmpd restart
   

That's the install done. At this point the agent is running — but on a stock Debian or Ubuntu build it's usually listening only on 127.0.0.1, which means nothing off-box can reach it yet. Opening it up and deciding who may read what is the job of the snmpd.conf guide; don't skip it, or your freshly installed agent stays invisible to every poller on the network.

Worth knowing what you've actually installed. The Net-SNMP agent doesn't just answer one thing — out of the box it publishes a broad standard tree. That includes the Host Resources MIB (RFC 2790) for uptime, CPU, memory, and storage, plus the IF-MIB (RFC 2863) for per-interface traffic counters. So the moment the daemon is reachable, it can serve dozens of useful metrics; your later config decides which of them you expose. Browse the sensor & OID catalog to see the full menu before you start trimming it down.

Configuration example

The whole install is five commands on Debian/Ubuntu:

You won't write the full access-control model here — that's owned by the snmpd.conf configuration guide — but two files matter the moment the package lands.

The daemon toggle in /etc/default/snmpd decides whether the service runs at all:

# /etc/default/snmpd
SNMPDRUN=yes      # run the agent
TRAPDRUN=no       # not sending traps in this setup

And the one change to /etc/snmp/snmpd.conf that takes the agent off localhost so remote polling works:

# /etc/snmp/snmpd.conf
agentAddress udp:161,udp6:[::1]:161

Out of the box you'll often find agentAddress udp:127.0.0.1:161 instead — that's the localhost-only binding that makes a fresh install look broken. Widen it to udp:161 (all interfaces) and, once you've confirmed it works, tighten access with a firewall rule and a non-default port. The community string, groups, and OID views go in this same file; head to the config guide for those lines.

Verify it works

Confirm two things: the service is up, and it answers over the network.

service snmpd status

A running, enabled unit is what you want. Now, from your second machine, walk the host uptime OID — hrSystemUptime, 1.3.6.1.2.1.25.1.1.0 from the Host Resources MIB (RFC 2790):

snmpwalk -v2c -c public <server-ip> 1.3.6.1.2.1.25.1.1.0

If MIB names are installed you'll see something like HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (123456) 0:20:34.56. That single line proves the install worked end to end — package present, service running, agent bound to a reachable interface, and community accepted. What that uptime figure is good for is covered on the uptime sensor page.

Read the failure modes closely, because each one points somewhere different. A timeout means the agent is still bound to localhost, or a firewall is dropping UDP 161 between you and the host. An authorization error — or a walk that returns nothing at all — means the default community doesn't match what's in the config. And snmpwalk: command not found on the client simply means the snmp package didn't land on the machine you're testing from. Fix the binding and reachability first; only then is it worth debugging communities and views. Testing from localhost would mask exactly the network faults that matter, so always query across the wire.

Security note

A just-installed agent is not a secure one. Before it faces anything beyond your lab:

• Change the community string immediately. The stock public is a known password — see Secure the community string.
• Keep it read-only. Don't add write access you'll never use.
• Restrict the source. Firewall UDP 161 (or your custom port) to the poller's IP.
• Enable MIBs deliberately, not blindly — only where you need readable output.
• Review the full model on the security overview before exposing the host to the public internet.

Installation and hardening are two different tasks. Finishing the first without the second leaves a server broadcasting its internals to anyone who asks.

Next: connect external monitoring

Once snmpd answers, you've got data — but only if something is asking for it, continuously, from a vantage point the server can't take down with it. A local cron poller dies with the machine. An external one doesn't. That separation is the whole point of double durability: keep a watcher outside the network so a crashed or overloaded host still generates an alert instead of silence.

ostr.io Monitoring does this without any extra software on the server — the SNMP agent you just installed is all it needs. It polls your endpoint from the outside and sends real-time email and SMS alerts when a value crosses a threshold. The add-endpoint guide shows how to register this server in a couple of minutes.