snmpd.conf: The Complete Configuration Guide

By the SNMP Monitoring team · Reviewed July 2026

Every decision about who can read your agent, what they can see, and how the box identifies itself lives in one file: snmpd.conf. Get it right and SNMP is a tidy read-only window on a trusted segment; get it wrong and it's an open door. This is the working reference for the net-snmp directives that matter — listen address, the community and SNMPv3 access models, VACM views to restrict OIDs, system info, traps, and extend — ending in a secure example you can adapt.

Parent: setup. Install first via Ubuntu/Debian or CentOS/RHEL.

File location & reload

The net-snmp agent reads /etc/snmp/snmpd.conf. After editing, apply changes by restarting the service:

sudo systemctl restart snmpd

net-snmp can also reload configuration on a SIGHUP without a full restart, but a systemctl restart is the reliable, unambiguous way to be sure your changes took effect. The safe edit loop:

1. Edit /etc/snmp/snmpd.conf.
2. Restart with sudo systemctl restart snmpd.
3. Confirm it started cleanly (systemctl status snmpd) — a syntax error can stop it.
4. Verify the intended access with a snmpwalk from the manager.

Always test afterward — a typo in snmpd.conf can leave the daemon running on old config or refusing to start, and you want to catch that now, not during an incident.

Listen address (agentAddress)

By default many distros bind snmpd to localhost only. To expose it, set agentAddress:

agentAddress udp:161,udp6:[::1]:161

That binds UDP 161 on IPv4 and IPv6. In production, bind to the management interface's address rather than all interfaces, so the agent isn't reachable from networks that have no business polling it. The listen address is your first line of defence — an agent that doesn't listen on the internet-facing NIC can't be scanned from there.

Access: the community model (v2c)

For SNMPv1/v2c, the simplest directive is rocommunity (read-only) with an optional source restriction:

rocommunity S3cr3tR0str1ng 10.0.0.5

That grants read-only access with the given community, but only from 10.0.0.5. Avoid rwcommunity (read-write) unless you genuinely need SetRequests — write access to an agent is a large risk. For finer control, net-snmp exposes the full VACM chain:

The com2sec → group → view → access chain is verbose but it's how you express "this community, from this subnet, may read only this part of the tree."

Access: SNMPv3 (createUser / rouser)

For authenticated, encrypted access, define a v3 user. In snmpd.conf (or the createUser line, often placed in /var/lib/snmp/snmpd.conf and migrated on first start):

createUser monitor SHA "AuthPass_change_me" AES "PrivPass_change_me"
rouser monitor priv

createUser sets the username with SHA authentication and AES encryption passphrases; rouser monitor priv grants that user read-only access at the authPriv level (authenticated and encrypted). This is the preferred model — a sniffed v3 packet reveals neither credentials nor data. Details on the security levels are on SNMPv3 setup.

Limiting OIDs with VACM views

Even a read-only agent shouldn't expose its entire tree — a leaked community then dumps everything. Restrict the readable subtree with a view:

view mymetrics included 1.3.6.1.2.1.1
view mymetrics included 1.3.6.1.2.1.25
access mygroup "" any noauth exact mymetrics none none

The view lines whitelist just the system and host-resources subtrees; the access line binds a group to that view. Now a compromised community reads only what you allowed, not the whole MIB. This OID-allowlist pattern is covered in depth on OID allowlist.

System info & traps

Set the agent's identity and, if you use trap-based alerting, a destination:

sysLocation Rack 12, DC-East
sysContact netops@example.com
sysServices 72
trap2sink 10.0.0.9 TrapCommunity

sysLocation and sysContact populate the standard system group — genuinely useful when an alert fires and you need to know which box and who owns it. trap2sink sends SNMPv2c traps to a manager. Trap versus poll trade-offs are on traps vs polling.

Extending the agent

To expose a metric no MIB covers, run a command with extend:

extend queuedepth /usr/local/bin/queue_depth.sh

The output appears under the NET-SNMP-EXTEND-MIB, pollable like any OID. The mechanics — extend vs pass, where the output lands, choosing an enterprise OID — are on custom OIDs.

A secure example config

A minimal, defensible v3-first snmpd.conf:

agentAddress udp:10.0.0.20:161
createUser monitor SHA "AuthPass_change_me" AES "PrivPass_change_me"
rouser monitor priv
view mymetrics included 1.3.6.1.2.1.1
view mymetrics included 1.3.6.1.2.1.25
view mymetrics included 1.3.6.1.2.1.2
access notConfigGroup "" usm priv exact mymetrics none none
sysLocation Rack 12, DC-East
sysContact netops@example.com

It binds to one management IP, uses a v3 authPriv user, and exposes only the system, host-resources, and interface subtrees. Adapt the addresses, passphrases, and views to your environment — and change every placeholder before deploying.

A final word on distro defaults, because they cause a lot of confusion. A fresh snmpd.conf from your package manager is rarely empty — Debian/Ubuntu and the RHEL family ship different starter configs, sometimes with a restrictive default view (systemonly) that exposes only the system group, sometimes with an rocommunity public example you must remove. So don't assume a directive you add is the only one in effect; read the whole file, comment out or delete the vendor examples you're replacing, and confirm the net result with a snmpwalk rather than trusting that your additions won. When two directives conflict, the safest habit is to strip the shipped config down to exactly what you intend and build up from there.

Frequently asked questions

Where is snmpd.conf?

The net-snmp agent's main config is /etc/snmp/snmpd.conf. There's often a second, persistent file at /var/lib/snmp/snmpd.conf where net-snmp stores created v3 users after first start. Distro option files (/etc/default/snmpd, or a sysconfig file on RHEL) control daemon flags like the listen address.

What is rocommunity?

rocommunity <string> [source] is the quick way to grant SNMPv1/v2c read-only access with a community string, optionally restricted to a source IP or subnet. It's shorthand for the longer com2sec/group/view/access chain. Use a random string, never public, and add a source restriction.

How do I add a v3 user?

Add createUser <name> SHA "<authpass>" AES "<privpass>" to define the user with authentication and encryption, then rouser <name> priv to grant read-only access at the authenticated-and-encrypted level. Restart snmpd; net-snmp migrates the createUser line into its persistent state on first start.

How do I restrict which OIDs are readable?

Define a VACM view listing the subtrees you want visible (view name included <oid>), then bind it in an access line. A read-only agent still exposes its whole tree unless you scope it, so an OID allowlist limits what a leaked community or credential can read.

Key takeaways

• Config lives in /etc/snmp/snmpd.conf; restart snmpd and test after every edit.
• agentAddress controls what the agent listens on — bind to the management interface.
• Prefer SNMPv3 (createUser + rouser … priv); use rocommunity only with a random string + source IP.
• Avoid rwcommunity unless you truly need writes.
• Scope exposure with VACM view/access — an OID allowlist limits a leaked credential.
• Set sysLocation/sysContact; expose custom metrics with extend.