---
type: Article
title: "Install snmpd on Ubuntu/Debian"
description: "Install snmpd on Ubuntu or Debian the right way: the apt-get command, the /etc/default/snmpd toggle that turns the agent on, and a first walk to prove it."
resource: "https://snmp-monitoring.com/setup/install-snmpd-ubuntu-debian/"
tags: [setup, snmp]
timestamp: 2026-07-13T00:00:00Z
---

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

![Terminal screenshot: running apt-get install snmpd on Ubuntu, then editing SNMPDRUN in /etc/default/snmpd](https://snmp-monitoring.com/img/setup/apt-get-install-snmpd.webp)

## 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:
   ```bash
   sudo apt-get update
   ```
2. **Run the apt-get install snmpd command.** Pull the daemon plus the client tools in one go:
   ```bash
   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:
   ```bash
   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`:
   ```bash
   sudo nano /etc/default/snmpd
   ```
   and set:
   ```bash
   SNMPDRUN=yes
   TRAPDRUN=no
   ```
5. **Restart and enable at boot:**
   ```bash
   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](/setup/snmpd-conf.md); 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](/sensors/index.md) to see the full menu before you start trimming it down.

## Configuration example

The whole install is five commands on Debian/Ubuntu:

| Step | Command | Purpose |
|---|---|---|
| Update index | `apt-get update` | refresh package lists |
| Install | `apt-get install snmpd` | install the SNMP daemon |
| Edit config | `nano /etc/snmp/snmpd.conf` | configure access + views |
| Restart | `service snmpd restart` | apply changes |
| Check | `service snmpd status` | confirm `active (running)` |


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

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

```bash
# /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:

```bash
# /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](/setup/custom-port.md). 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.

```bash
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):

```bash
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](/sensors/server-resources/uptime-reboot.md).

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](/setup/secure-community-string.md).
- **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](/security/index.md) 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](/monitoring/double-durability.md): keep a watcher outside the network so a crashed or overloaded host still generates an alert instead of silence.

[ostr.io Monitoring](https://ostr.io/service/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](/setup/add-endpoint-ostrio.md) shows how to register this server in a couple of minutes.

![Diagram: a freshly installed snmpd agent on a Debian server answering an snmpwalk from a separate client machine over UDP](https://snmp-monitoring.com/img/setup/snmpd-install-verify.webp)

## FAQ

**What's the difference between the `snmpd` and `snmp` packages?**
`snmpd` is the agent daemon that answers queries on the server. `snmp` provides the client utilities — `snmpwalk`, `snmpget`, `snmptable` — you use to test and poll. Install both; put `snmpd` on the monitored host and `snmp` wherever you query from.

**I ran apt-get install snmpd but nothing answers. Why?**
Two usual causes. Either `SNMPDRUN` isn't set to `yes` in `/etc/default/snmpd`, or the agent is still bound to `127.0.0.1` in `snmpd.conf`. Fix both, restart, and test from another machine.

**Do I need snmp-mibs-downloader?**
No — it only affects readability. Without it, output shows numeric OIDs instead of names like `hrSystemUptime`. Polling and alerting work either way.

**Is the install any different on Debian versus Ubuntu?**
No. The `apt-get install snmpd` command, the `/etc/default/snmpd` toggle, and the config file paths are identical across current Debian and Ubuntu releases.

## Conclusion

To install snmpd on Ubuntu or Debian, the mechanics are trivial: `apt-get install snmpd snmp`, optionally add `snmp-mibs-downloader`, set `SNMPDRUN=yes`, widen `agentAddress` off localhost, and restart. The part that decides whether it's useful comes next — writing the access rules, securing the community, and pointing an external checker at the endpoint so your monitoring survives the very outages it exists to catch. Install first, then harden, then watch from outside.