Book HomeEssential SNMPSearch this book

F.2. Configuring SNMPv3

Now we get to put the SNMPv3 concepts to use. We'll look at two examples: configuring a Cisco router and setting up the Net-SNMP tools on a system running Unix. The concepts are the same for both entities; the only difference is how you configure SNMPv3.

Most of the work in administering SNMPv3 has to do with managing users and their passwords. It shouldn't be surprising that the table of users, passwords, and other authentication information is just another SNMP table, called usmUser. The table's full object ID is usmUser ; the numeric form is .

F.2.1. Configuring SNMPv3 for a Cisco Router

Chapter 7, "Configuring SNMP Agents" describes how to configure SNMP on a Cisco router. This section assumes that you're already familiar with IOS and that we don't have to tell you the basics, such as how to log into the router and get to privileged mode. It also assumes that you've read Chapter 7, "Configuring SNMP Agents" and have configured basic SNMP on your router.

The first task in configuring SNMPv3 is to define a view. To simplify things, we'll create a view that allows access to the entire internet subtree:

router(config)#snmp-server view readview internet included
This command creates a view called readview. If you want to limit the view to the system tree, for example, replace internet with system. The included keyword states that the specified tree should be included in the view; use excluded if you wanted to exclude a certain subtree.

Next, create a group that uses the new view. The following command creates a group called readonly ; v3 means that SNMPv3 should be used. The auth keyword specifies that the entity should authenticate packets without encrypting them; read readview says that the view named readview should be used whenever members of the readonly group access the router.

router(config)#snmp-server group readonly v3 auth read readview
Now let's create a user. The following command creates a user called kschmidt, who belongs to the readonly group. auth md5 specifies that the router should use MD5 to authenticate the user (the other possibility is sha). The final item on the command line is the user's password or passphrase, which may not exceed 64 characters.

router(config)#snmp-server user kschmidt readonly v3 auth md5 mysecretpass
This configuration uses encryption only to prevent passwords from being transferred in the clear. The SNMP packets themselves, which may contain information that you don't want available to the public, are sent without encryption and can therefore be read by anyone who has a packet sniffer and access to your network. If you want to go a step further and encrypt the packets themselves, use a command like this:

router(config)#snmp-server user kschmidt readonly v3 auth md5 mysecretpass \ 
priv des56 passphrase
The additional keywords on this command specify privacy (i.e., encryption for all SNMP packets), use of DES 56-bit encryption, and a passphrase to use when encrypting packets.

The encrypted passwords and passphrases depend on the engine ID, so if the engine ID changes you'll need to delete any users you have defined (with the familiar IOS no command), and recreate them (with snmp-server user commands). Why would the engine ID change? It's possible to set the engine ID on the IOS command line. You shouldn't ever need to set the engine ID explicitly, but if you do, you'll have to delete and recreate your users.

This has been the briefest of introductions to configuring SNMPv3 on a Cisco router. For more information see Cisco's documentation, which is available at

F.2.2. Configuring SNMPv3 for Net-SNMP

Chapter 7, "Configuring SNMP Agents" describes basic configuration for Net-SNMP. In this section, we discuss how to configure Net-SNMP's Version 3 features. First, we will discuss how to configure SNMPv3 by editing the snmpd.conf [82] files. Note that you must install OpenSSL before editing the files if you want to use either DES or SHA. OpenSSL is available from

[82]There are two snmpd.conf files in play here: the normal /usr/share/snmp/snmpd.conf file and the persistent /var/ucd-snmp/snmpd.conf file. The persistent file will be discussed momentarily.

To create a user named kschmidt who has read-write access to the system subtree, add the following line to your snmpd.conf file:

rwuser  kschmidt auth system
To create a user with read-only access, use the command rouser instead of rwuser. The auth keyword requests secure authentication, but not privacy: the SNMP packets themselves aren't encrypted. The other possibilities are noauth (no authentication and no privacy) and priv (authentication and privacy). Now add the following line to /var/ucd-snmp/snmpd.conf:

createUser kschmidt MD5 mysecretpass
This creates an MD5 password for the user kschmidt. The password assigned to kschmidt is mysecretpass. To create a user with a DES passphrase in addition to an MD5 password, add the following line to /var/ucd-snmp/snmpd.conf:

createUser kschmidt MD5 mysecretpass DES mypassphrase
If you omit mypassphrase, Net-SNMP sets the DES passphrase to be the same as the MD5 password. The RFCs for SNMPv3 recommend that passwords and passphrases be at least eight characters long; Net-SNMP enforces this recommendation and won't accept shorter passwords.

After making these changes, stop and restart the agent. When the agent is started, it reads the configuration file, computes secret keys for the users you have added, and deletes the createUser commands from the file. It then places the secret key in the configuration file. This behavior has a number of consequences. The secret key is based on the engine ID, which for Net-SNMP is based on the IP address. Therefore, you can't copy configuration files from one machine to another. Furthermore, if you change a machine's IP address, you will have to reconfigure Net-SNMP: stop the agent, edit /var/ucd-snmp/snmpd.conf, delete any entries Net-SNMP has added for your users, add createUser commands to recreate your users, and start the agent again.

Now we can perform an snmpwalk using Version 3 authentication. The following command specifies Version 3, with the username kschmidt, requesting authentication without privacy using the MD5 algorithm. The password is mysecretpass:

$ snmpwalk -v 3 -u kschmidt -l authNoPriv -a MD5 -A mysecretpass \
system.sysDescr.0 = Linux server 2.2.14-VA.2.1 #1 Mon Jul 31 21:58:22 PDT 2000 i686
system.sysObjectID.0 = OID: enterprises.ucdavis.ucdSnmpAgent.linux
system.sysUpTime.0 = Timeticks: (1360) 0:00:13.60
system.sysContact.0 = "Ora Network Admin"
system.sysName.0 = server
system.sysLocation.0 = "Atlanta, Ga"
system.sysServices.0 = 0
system.sysORLastChange.0 = Timeticks: (0) 0:00:00.00
system.sysORTable.sysOREntry.sysORID.1 = OID: ifMIB
system.sysORTable.sysOREntry.sysORUpTime.9 = No more variables left in this MIB View
Note that we see only objects from the system subtree, even though the command tries to walk the entire tree. This limitation occurs because we have given kschmidt access only to the system subtree. If kschmidt tries to query a subtree he is not allowed to access, he gets the following result:

$ snmpwalk -v 3 -u kschmidt -l authNoPriv -a MD5 -A mysecretpass \ interfaces
interfaces = No more variables left in this MIB View
If you want privacy in addition to authentication, use a command like this:

$ snmpwalk -v 3 -u kschmidt -l authPriv -a MD5 -A mysecretpass -x DES -X \
Remember that to use DES privacy, you must install the OpenSSL library.

F.2.2.1. Using snmpusm to manage users

The Net-SNMP utility snmpusm is used to maintain SNMPv3 users. The following command creates the user kjs by cloning the kschmidt user:

$ snmpusm -v 3 -u kschmidt -l authNoPriv -a MD5 -A mysecretpass localhost create \ kjs kschmidt
Since kjs was cloned from kschmidt, the two users now have the same authorization, password, and passphrase. It's obviously essential to change kjs 's password. To do so, use snmpusm with the -Ca option. Similarly, to change the privacy passphrase, use -Cx. The following two commands change the password and passphrase for the new user kjs:

$ snmpusm -v3 -l authNoPriv -u kjs -a MD5 -A mysecretpass localhost passwd \
-Co -Ca mysecretpass mynewpass
$ snmpusm -v3 -l authPriv -u kjs -a MD5 -A mysecretpass localhost passwd \
-Co -Cx mypassphrase mynewphrase
There are many things to note about this seemingly simple operation:

  • You must know both the password and passphrase for kschmidt to set up a new password and passphrase for kjs.

  • According to the documentation, Net-SNMP allows you to clone any given user only once. It's not clear whether this means that you can create only one clone of a user or that once you have created a clone, you can't create a clone of that clone. In any case, this restriction doesn't appear to be enforced.

  • snmpusm can only clone users; it can't create them from scratch. Therefore, you must create the initial user by hand, using the process described above. (This isn't quite true. snmpusm can create a user, but once you've done so you have to assign it a password by changing its previous password. So you're in a catch-22: the new user doesn't have a password, so you can't change its password.)

For the user to be written to the persistent snmpd.conf file, you must either stop and restart the agent or send an HUP signal to the snmpd process. This forces the agent to write the current state of the user table to disk, so the agent can reread it upon startup. Note that kill -9 does not produce the desired result.

The snmpusm command exists primarily to allow end users to manage their own passwords and passphrases. As the administrator, you may want to change your users' passwords and passphrases periodically. This is possible only if you keep a master list of users and their passwords and passphrases.

If the engine ID changes, you will have to regenerate all the usernames, passwords, and passphrases. (Remember that the engine ID depends in part on the host's IP address and therefore changes if you have to change the address.) To do this, stop the agent and edit the /var/ucd-snmp/snmpd.conf file. Remove all the persistent usmUser entries and add new createUser commands (as described previously) for your users. A usmUser entry looks something like this:

usmUser 1 3 0x800007e580e134af77b9d8023b 0x6b6a7300 0x6b6a7300 NULL
. 0xb84cc525635a155b6eb5fbe0e3597873
. 0x1cfd8d3cadd95abce8efff7962002e24 ""

F.2.2.2. Simplifying commands by setting defaults

At this point you may be wondering why anyone would use SNMPv3, because the commands are so painfully long and complex that it's practically impossible to type them correctly. Fortunately, there's a way around this problem. Net-SNMP allows you to set configuration variables that the commands pick up when they execute. Create a directory in your home directory called .snmp, then edit the snmp.conf file. Add entries that look like this:

defSecurityName   kschmidt
defAuthType       MD5
defSecurityLevel  authPriv
defAuthPassphrase mysecretpass
defPrivType       DES
defPrivPassphrase mypassphrase
defVersion        3
The fields in this file are:

The SNMPv3 username.

The authentication method (either MD5 or SHA).

The security level for the user. Valid levels are noAuthNoPriv, authNoPriv, and authPriv.

Your password; must be at least eight characters long.

The privacy protocol to use. Only DES is supported at this time.

Your privacy passphrase; not needed if the security level is noAuthNoPriv or authNoPriv. Must be at least eight characters long.

The SNMP version to use (in this case, SNMPv3).

You can also use the snmpconf command to set up this file. snmpconf prompts you for the various passwords and keywords that need to be in the file. In our opinion, it's easier to write the file yourself.

Once you've created snmp.conf, you can use defaults to simplify your commands. For example, the following command:

$ snmpwalk -v3 -u kschmidt -l authPriv -a MD5 -A mysecretpass -x DES -X \ mypassphrase localhost

$ snmpwalk localhost
These defaults apply to all Net-SNMP commands, including snmpusm.

Library Navigation Links

Copyright © 2002 O'Reilly & Associates. All rights reserved.