How to Configure SNMPv3 (Authentication & Encryption)

By the SNMP Monitoring team · Reviewed July 2026

SNMPv3 is the version you actually want in production, because it's the only one that authenticates and encrypts. v1 and v2c send a cleartext community string that anyone on the path can capture; v3 replaces that with a real user, a hashed credential, and an encrypted payload. This is the step-by-step to a secure authPriv user on net-snmp — the three security levels, why SHA and AES, the exact user-creation syntax, and a snmpwalk -v3 to prove it.

Parent: setup. Background: SNMP versions; the trade-off: v3 vs v2c.

The three security levels

SNMPv3 (USM, RFC 3414) offers three levels, and only one is genuinely secure:

Use authPriv. noAuthNoPriv is no better than an open v2c agent, and authNoPriv authenticates the request but still sends your metrics in the clear. Only authPriv gives you both a verified identity and confidentiality — the whole reason to run v3.

Choosing auth & priv protocols

Within authPriv you pick an authentication (hash) protocol and a privacy (encryption) protocol. The modern choices:

• Authentication: prefer SHA (or the SHA-2 family where supported) over the legacy MD5, which is cryptographically broken.
• Privacy: prefer AES over DES, which has a 56-bit key and is trivially crackable today.
• Match both ends: the manager must use the same protocols and passphrases the agent was created with.
• Use distinct auth and priv passphrases, each at least 8 characters — net-snmp enforces a minimum.

In short: SHA + AES. MD5 and DES exist only for interop with ancient gear; don't choose them for anything new.

Step 1: Create a v3 user

net-snmp stores v3 users in its persistent config, and the safe way to add one is with the daemon stopped:

sudo systemctl stop snmpd
sudo net-snmp-create-v3-user -ro -A "AuthPass_change_me" -a SHA -X "PrivPass_change_me" -x AES monitor
sudo systemctl start snmpd

That creates a read-only (-ro) user named monitor, with SHA authentication and AES privacy. The command writes the user into net-snmp's persistent state (typically /var/lib/snmp/snmpd.conf). Alternatively, you can declare it directly in snmpd.conf:

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

On next start, net-snmp reads the createUser line, hashes and stores the credentials, and removes the plaintext line. Either route gets you the same result — pick the CLI helper for a running system, the config directive for provisioning/automation.

Step 2: Authorize the user (rouser)

Creating the user isn't enough; you authorize what it can read with rouser (and optionally scope it to a view):

rouser monitor priv

rouser monitor priv grants the monitor user read access at the authPriv level. To expose only part of the tree, bind it to a VACM view instead of granting the whole MIB — combine this with an OID allowlist so even an authenticated user sees only what it needs. Least privilege applies to v3 users just as it does to communities.

Step 3: Restart & test

Bring it together in order:

1. Restart the agent with sudo systemctl restart snmpd.
2. Confirm it came up cleanly (systemctl status snmpd) — a bad createUser line can stop it.
3. Run the authPriv walk below from the manager.
4. Check the returned data matches the box; a passphrase or protocol mismatch fails here.

snmpwalk -v3 -l authPriv -u monitor -a SHA -A "AuthPass_change_me" -x AES -X "PrivPass_change_me" <host> system

SNMPv2-MIB::sysDescr.0 = STRING: Linux db01 5.15.0-generic x86_64
SNMPv2-MIB::sysUpTime.0 = Timeticks: (45678901) 5 days, 6:53:09.01
SNMPv2-MIB::sysContact.0 = STRING: netops@example.com

The flags map directly: -l authPriv sets the level, -u the user, -a SHA -A the auth protocol and passphrase, -x AES -X the privacy protocol and passphrase. Data back means the user, both passphrases, and both protocols all match the agent. A authenticationFailure means a passphrase or protocol is wrong. Keep real passphrases out of shell history and committed scripts.

Engine ID & gotchas

The gotcha that catches people: v3 users are bound to the agent's engine ID, which is derived per host. This has one important consequence — if you clone a VM (or a golden image) that already has v3 users, the cloned agent inherits the source's engine ID material and the users can misbehave or fail to authenticate. The fix is to recreate the v3 users on the clone (or reset the engine ID), so each host has its own. Don't bake v3 users into a template and expect them to work unchanged across clones.

There's a second reason engine ID matters, and it's about how v3 stores passphrases. net-snmp doesn't keep your auth and priv passwords verbatim — it localises them, hashing each one together with the engine ID into a key that's specific to that agent. That's why the createUser line disappears after first start: the daemon has converted your plaintext into engine-bound key material and no longer needs the original. It's also why you can't simply copy /var/lib/snmp/snmpd.conf from one host to another and expect the users to work — the localised keys belong to the source engine ID, not the destination's. Provision v3 users per host, from configuration management that runs on each box, rather than by copying persistent state around.

One more operational note: keep your manager-side credentials in step with the agent. Because the passphrases and protocols must match exactly on both ends, a passphrase rotation is a two-sided change — update the agent (recreate the user) and the poller (its stored credential) together, or the next poll fails with an authenticationFailure. Treat v3 credentials like any other secret: rotate them on a schedule, store them in a secrets manager, and never leave the change_me placeholders from the examples above in a production config.

Frequently asked questions

How do I create an SNMPv3 user?

Stop snmpd, then run net-snmp-create-v3-user -ro -A "<authpass>" -a SHA -X "<privpass>" -x AES <username> and start snmpd again — that creates a read-only user with SHA auth and AES privacy. Alternatively add createUser <name> SHA "<authpass>" AES "<privpass>" plus rouser <name> priv to snmpd.conf.

What is authPriv?

authPriv is the SNMPv3 security level that provides both authentication (the request is verified with a hash) and privacy (the payload is encrypted). It's the secure level to use — the other two, noAuthNoPriv and authNoPriv, either skip authentication entirely or leave your metrics in cleartext.

SHA vs MD5, AES vs DES — which should I use?

Use SHA (or SHA-2) for authentication and AES for privacy. MD5 is cryptographically broken and DES has a 56-bit key that's trivially crackable, so both survive only for interoperability with legacy equipment. For anything new, SHA + AES is the correct choice.

Why does my v3 user stop working after cloning a VM?

Because SNMPv3 users are tied to the agent's engine ID, and cloning a VM duplicates the engine ID material from the source image. The cloned host's users can then fail to authenticate. Recreate the v3 users (or reset the engine ID) on each clone so every host has its own identity.

Key takeaways

• Use authPriv — the only v3 level with both authentication and encryption.
• Prefer SHA + AES; avoid MD5 and DES (both broken/weak).
• Create users with net-snmp-create-v3-user -ro -a SHA -x AES or createUser + rouser … priv.
• Authorize with rouser; scope with a VACM allowlist for least privilege.
• Test with snmpwalk -v3 -l authPriv -u … -a SHA -A … -x AES -X ….
• v3 users bind to the engine ID — recreate them after cloning a VM.
• For off-box checks where v3 isn't available, an external SNMPv2c poller like ostr.io pairs a random community with an allowlist — see external monitoring.