SNMPv3 authentication failure, unknown user and usmStats counters

Q: Why does snmpget say Unknown user name?

The agent answered with a Report usmStatsUnknownUserNames: it has no user with that name. Check the spelling and the case, and check that the user exists on this agent. The agent looks up the user before any password, so the passwords play no part at this step.

An SNMPv3 agent runs each request through the User-based Security Model (USM, RFC 3414) and keeps a counter for each kind of failure. snmpget turns the agent’s reply into a short error line, and some agents send no reply, so one mistake can look different on two devices. The output below comes from snmpget (net-snmp 5.9.4) in the developer’s network on November 11, 2026, against a Linux host with net-snmp snmpd (192.0.2.12) and a MikroTik RB4011 on RouterOS 7.25 (192.0.2.1); 192.0.2.x stands in for the real addresses, and <community> and <user> for the community and the user name.

snmpget: Unknown user name
Authentication failure (incorrect password, community or key)
Timeout: No Response for an unknown user
Timeout with a wrong privacy password
Read the usmStats counters over v2c
The six usmStats counters

snmpget: Unknown user name

$ snmpget -v3 -l authPriv -u nosuchuser -a SHA -A wrongpass123 -x AES -X wrongpriv123 192.0.2.12 sysUpTime.0
snmpget: Unknown user name
[exit 1]

The net-snmp agent answered with a Report that carries usmStatsUnknownUserNames, and snmpget printed it as Unknown user name. The agent looks up the user before it checks any password, so the two wrong passwords in this command made no difference.

Compare the name character by character with the user on the agent. USM matches names as exact strings: Monitor and monitor are two different users. Then confirm the user exists on this agent. On net-snmp, snmpd reads createUser lines when it starts, so restart it after you add a user.

Authentication failure (incorrect password, community or key)

$ snmpget -v3 -l authPriv -u <user> -a SHA -A wrongpass123 -x AES -X wrongpriv123 192.0.2.12 sysUpTime.0
snmpget: Authentication failure (incorrect password, community or key)
[exit 1]

This time the agent knew <user>. It computed the digest of the request with the key it stores for that user, got a different value, counted usmStatsWrongDigests and sent a Report. Ignore the word “community” in the line: with SNMPv3 it points at two settings, the auth password and the auth protocol.

Wrong auth protocol: MD5 instead of SHA

$ snmpget -v3 -l authPriv -u <user> -a MD5 -A wrongpass123 -x AES -X wrongpriv123 192.0.2.12 sysUpTime.0
snmpget: Authentication failure (incorrect password, community or key)
[exit 1]

This command differs from the one above in -a MD5 alone and keeps the wrong password. The output stays the same. The right password with MD5 in place of SHA fails at the same check. The client derives its key and computes the digest with the protocol you pass in -a. The agent checks that digest with the key and the hash it stores for the user, so a different protocol on either side gives a different digest. The Report doesn’t say which setting is wrong, so check both. MD5, SHA-1 (-a SHA in net-snmp), SHA-224, SHA-256, SHA-384 and SHA-512 are separate protocols, and each user on the agent has one of them.

Timeout: No Response for an unknown user

$ snmpget -v3 -l authPriv -u nosuchuser -a SHA -A wrongpass123 -x AES -X wrongpriv123 192.0.2.1 sysUpTime.0   # RouterOS
Timeout: No Response from 192.0.2.1.
[exit 1]

The same unknown user got no reply from the MikroTik. The router was up: in the same session it answered a v2c GET with the right community.

$ snmpget -v2c -c <community> 192.0.2.1 sysDescr.0 sysUpTime.0
SNMPv2-MIB::sysDescr.0 = STRING: RouterOS RB4011iGS+5HacQ2HnD 7.25
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (138807700) 16 days, 1:34:37.00
[exit 0]

The net-snmp agent sent a Report for the unknown user, and RouterOS 7.25 sent nothing. From the client, that silence looks the same as a firewall or a stopped agent, and a timeout proves no cause on its own. Rule out the network side with the Timeout: No Response guide, then compare the user name with the router’s SNMP settings.

Timeout with a wrong privacy password

In SNMP Inspector’s test lab, a request with the right user, the right auth password and a wrong AES-128 privacy password got no reply from a net-snmp 5.9.4 agent. The client saw a plain timeout.

The agent tests privacy after it accepts authentication. RFC 3414 orders the checks an agent runs on an incoming request: engine ID, user name, security level, digest, time window, and decryption last. With a wrong auth password the agent stops at the digest and never touches the privacy key. The two Authentication failure commands on this page carried a wrong privacy password too, and usmStatsDecryptionErrors below stayed at 0. In USM the privacy key comes from the privacy password through the hash of the auth protocol (RFC 3414), so a wrong auth protocol gives a different privacy key too.

To separate auth from privacy, send one request at -l authNoPriv if the user’s access rule allows that level. A Response, even one with an error status, means the agent accepted the auth settings, and a timeout at authPriv then points at privacy: the protocol (DES, AES-128, AES-192 or AES-256), the password, and for the longer AES keys the key extension variant, which must match on both sides.

Read the usmStats counters over v2c

A client sees at most one Report per request. The agent keeps the totals in SNMP-USER-BASED-SM-MIB, and you can read them over v2c while v3 still fails. After the three v3 commands above, the Linux agent showed:

$ snmpget -v2c -c <community> 192.0.2.12 usmStats*.0
SNMP-USER-BASED-SM-MIB::usmStatsUnsupportedSecLevels.0 = Counter32: 0
SNMP-USER-BASED-SM-MIB::usmStatsNotInTimeWindows.0 = Counter32: 0
SNMP-USER-BASED-SM-MIB::usmStatsUnknownUserNames.0 = Counter32: 1
SNMP-USER-BASED-SM-MIB::usmStatsUnknownEngineIDs.0 = Counter32: 3
SNMP-USER-BASED-SM-MIB::usmStatsWrongDigests.0 = Counter32: 2
SNMP-USER-BASED-SM-MIB::usmStatsDecryptionErrors.0 = Counter32: 0
[exit 0]

To read the same six values by number, walk 1.3.6.1.6.3.15.1.1.

The counts match the commands: one unknown user and two wrong digests, from the SHA run and the MD5 run. The 3 in usmStatsUnknownEngineIDs is first-contact behavior. Each snmpget run starts without a cached engine ID, so it opens with engine discovery, a request with an empty engine ID (RFC 3414, section 4). The agent counts that request as an unknown engine ID and answers with a Report that carries its own snmpEngineID. Three runs made three discoveries. A poller that keeps the engine ID between requests adds one count when it starts.

The counters run from the agent’s start and include every manager that talks to it. On a device that a monitoring system polls, read them before and after your test and compare.

RouterOS 7.25 answered No Such Object for usmStatsUnknownUserNames and for the v2c counter snmpInBadCommunityNames:

$ snmpget -v2c -c <community> 192.0.2.1 snmpInBadCommunityNames.0 usmStatsUnknownUserNames.0
SNMPv2-MIB::snmpInBadCommunityNames.0 = No Such Object available on this agent at this OID
SNMP-USER-BASED-SM-MIB::usmStatsUnknownUserNames.0 = No Such Object available on this agent at this OID
[exit 0]

On this router you can’t count unknown users over SNMP, and a failed v3 request leaves you the client-side result.

The six usmStats counters

Counter	OID	The agent counts a request when	What to check
`usmStatsUnsupportedSecLevels`	`1.3.6.1.6.3.15.1.1.1.0`	it asks for a security level the user or the agent doesn’t support	`-l` against the level of the user on the agent
`usmStatsNotInTimeWindows`	`1.3.6.1.6.3.15.1.1.2.0`	its boots and time values fall outside the agent’s 150-second window	One count after an agent restart is normal. Steady growth: two agents with one `snmpEngineID`
`usmStatsUnknownUserNames`	`1.3.6.1.6.3.15.1.1.3.0`	its user name isn’t in the agent’s user table	Spelling, case, and that the user exists on this agent
`usmStatsUnknownEngineIDs`	`1.3.6.1.6.3.15.1.1.4.0`	it carries an engine ID other than the agent’s, including the empty one of each discovery	One count per new client is normal. Growth with failures: a fixed engine ID in the client (`-e`)
`usmStatsWrongDigests`	`1.3.6.1.6.3.15.1.1.5.0`	its digest doesn’t match the key the agent stores for the user	Auth password and auth protocol
`usmStatsDecryptionErrors`	`1.3.6.1.6.3.15.1.1.6.0`	the agent can’t decrypt it	Privacy protocol, password and key variant

snmpEngineTime counts seconds since snmpEngineBoots last changed, so NTP on the phone or the switch has no effect on the time window. After an agent restart, a manager with cached values gets one usmStatsNotInTimeWindows Report, learns the new values from it and sends the request again.

Security level and user

Each user on the agent has an auth protocol or none, and a privacy protocol or none. A request at a level the user lacks, such as -l authPriv for a user without a privacy protocol, counts in usmStatsUnsupportedSecLevels. The agent checks the user name before the level, so a Report with this counter confirms that the user exists.

Checklist in order

The steps follow the order in which the agent checks a request.

Reach the agent. A v2c reply with a known community, or any Report over SNMPv3, proves the address, the port and the path. For total silence, start with the timeout guide.
Engine ID. Leave -e out and let discovery find the engine ID.
User name. Exact spelling and case. Unknown user name or a growing usmStatsUnknownUserNames puts the problem here.
Security level. -l must match a level the user has on the agent. Watch usmStatsUnsupportedSecLevels.
Auth protocol and password. Check them as a pair, since Authentication failure covers both. Test at -l authNoPriv if the access rule allows it.
Privacy protocol and password. Test them after step 5 passes. A timeout with steps 3-5 clean points here.
Context name. If you set one with -n and get silence, send the same GET in the default context.

The same checks in SNMP Inspector

The connection doctor in SNMP Inspector runs this order in three steps on your iPhone or iPad: engine discovery, a user check at noAuthNoPriv, then a GET at your security level. It names the Report it got and skips the steps after a failure:

Unknown user: “User is unknown to the agent”, with the line “answered the user check with Report usmStatsUnknownUserNames”.
Wrong digest: “Authentication failed. Check the auth password or protocol.”
Privacy after a failed auth: “Fix the auth settings first. The doctor tests privacy after the agent accepts authentication.”
Silent authPriv after the first two steps pass: “Privacy settings may not match. Check the password, protocol or key variant.” The doctor marks this result as Likely.

The doctor never reports a timeout as a wrong password. The demo SNMPv3 device in the app shows the unknown user, the failed authentication and the privacy mismatch before you connect your own switch.

Questions

What does usmStatsWrongDigests mean?

The agent found the user, computed the digest with the key it stores for that user and got a different value. The auth password or the auth protocol differs from the agent's settings. net-snmp prints this Report as Authentication failure (incorrect password, community or key).

Why does snmpget say Unknown user name?

The agent answered with a Report usmStatsUnknownUserNames: it has no user with that name. Check the spelling and the case, and check that the user exists on this agent. The agent looks up the user before any password, so the passwords play no part at this step.

Is a growing usmStatsUnknownEngineIDs counter a problem?

One count per new client is normal. A client without a cached engine ID starts with engine discovery, a request with an empty engine ID, and the agent counts it here. Three snmpget runs gave a count of 3 in the test on this page. Look closer if it grows along with failed requests from a client that sets a fixed engine ID with -e.

Why does SNMPv3 time out when the user and auth password are right?

Check the privacy protocol and password. In SNMP Inspector's test lab, a wrong AES-128 privacy password got no reply from a net-snmp agent. A context name and the network path can also end in silence: see Timeout: No Response.

What causes usmStatsNotInTimeWindows?

The boots and time values in an authenticated request fall outside the agent's 150-second window. A manager that cached them before the agent restarted gets one such Report and resynchronizes. Steady growth can mean two agents share one snmpEngineID. NTP plays no part: snmpEngineTime counts seconds since snmpEngineBoots last changed.