|SNMPD.CONF(5)||File Formats Manual||SNMPD.CONF(5)|
Simple Network Management Protocol daemon configuration
snmpd.conf is the configuration file for
the snmpd(8) daemon.
snmpd.conf file is divided into the
following main sections:
The current line can be extended over multiple lines using a backslash (‘\’). Comments can be put anywhere in the file using a hash mark (‘#’), and extend to the end of the current line. Care should be taken when commenting out multi-line text: the comment is effective until the end of the entire block.
Argument names not beginning with a letter, digit, or underscore must be quoted.
Additional configuration files can be included with the
include keyword, for example:
Macros can be defined that will later be expanded in context.
Macro names must start with a letter, digit, or underscore, and may contain
any of those characters. Macro names may not be reserved words (for example,
oid). Macros are not expanded inside quotes.
ext_addr="192.168.0.1" listen on $ext_addr
The following options can be set globally:
yes, snmpd(8) will filter out the OPENBSD-PF-MIB::pfTblAddrTable tree. Addresses stored in PF tables will not be available, but CPU use will be reduced during bulk walks. The default is
yes, ask the kernel to filter route update messages on the routing socket. Routing table information will not be available, but CPU use will be reduced during bulk updates. The default is
listen onaddress [
listen onstatements are supported, the default is UDP.
If the chosen value is different from
will accept only SNMPv3 requests since older versions neither support
authentication nor encryption.
OpenBSD myhost.example.com 4.2 GENERIC#595 i386
trap handleoid "command"
commandupon receipt of an SNMP trap that begins with a prefix of
oid. Alternately, the string "
default" may be used, in which case the prefix used is
1.3. The invoked command will receive the following information about the trap on standard input, one per line, in this order: the resolved hostname of the host sending the trap, the IP address of the host sending the trap, and any variable bindings contained in the trap (the OID followed by the value, separated by a single space). Traps will will be accepted on all
listen onUDP addresses.
trap receiverstring [
trap communityoption. The IPv4 or IPv6 source address of the traps can be enforced using
Users for the SNMP User-based Security Model (USM, RFC 3414) must be defined in the configuration file:
authkeykeyword is required to specify the digest key used to authenticate messages. If this keyword is omitted then authentication is disabled for this user account. Optionally the HMAC algorithm used for authentication can be specified. hmac must be either
hmac-sha512. If omitted the default is
enckey the encryption key used to
encrypt and decrypt messages for privacy is defined. Without an
enckey specification the user account will
neither accept encrypted incoming messages nor will it encrypt outgoing
messages. The enc algorithm can be either
aes and defaults
Any user account that has encryption enabled requires authentication to be enabled too.
It is possible to specify user-defined OIDs in the configuration file:
read-write] [type] value
read-writeoption may allow the client to override it, and the type is either
The following example will tell snmpd(8) to listen on localhost, override the default system OID, set the magic services value and provides some custom OID values:
listen on 127.0.0.1 system oid 188.8.131.52.4.1.30155.23.2 system services 74 oid 184.108.40.206.4.1.30155.42.1 name myName read-only string "humppa" oid 220.127.116.11.4.1.30155.42.2 name myStatus read-only integer 1
The next example will enforce SNMPv3 with authenticated and
encrypted communication and the user-based security model. The configuration
defines two users, the first one is using the
encryption algorithm and the second one the default
seclevel enc user "hans" authkey "password123" enc aes enckey "321drowssap" user "sophie" authkey "password456" enckey "654drowssap"
snmpd.conf file format first appeared
in OpenBSD 4.3.
|June 30, 2020||OpenBSD-current|