SNMP Linux: Install and Configure the Agent

Preparing a Linux machine for monitoring means setting up a way for the monitoring system to request its status. SNMP lets a monitoring manager make those requests through an agent running on the host.

This article explains what the Linux agent does and shows how to install and configure it for read-only queries on Debian or Ubuntu.

TL;DR

On Debian or Ubuntu, install the Net-SNMP client and agent, then allow read-only queries from the monitoring host only. Check the agent locally before testing the network path.

• The snmp package provides client commands. The snmpd package runs the agent.
• Bind the agent to its private address and restrict its community to the manager address.
• SNMPv2c does not encrypt its community. Keep it on a trusted network or use SNMPv3 with authentication and privacy.

What SNMP Does on a Linux Host

SNMP lets a monitoring manager request structured status data from an agent running on a host. Net-SNMP supplies the Linux agent and the command-line client tools, but each belongs to a separate package.

A normal poll uses UDP port 161. The manager supplies a version and access credential, then asks for an object identifier, or OID. With SNMPv2c, that credential is a community string sent without encryption, so an address restriction reduces who may query but does not hide the string from network observers.

This walkthrough uses numeric OIDs first because the initial transport test should not depend on locally installed MIB name mappings. A MIB maps numeric identifiers to names, but the underlying OID remains the value the agent answers.

A manager can request one OID or walk a subtree. The snmpwalk client follows successive object identifiers with GETNEXT requests until it reaches the end of the requested branch or the agent stops answering. Starting with the system branch keeps the test focused on basic host information rather than every value exposed by the agent.

How to Install and Configure SNMP on Debian or Ubuntu

The procedure installs both package roles, binds the agent to its private IPv4 address, and checks localhost before the remote manager. Replace the documentation addresses with the host and manager addresses on your own network. In this piece, I’ll keep the example read-only and separate local agent checks from the remote network path.

Step 1: Check whether the packages are installed

Query dpkg before installing anything. When neither package is present, the command exits with status 1 and reports no matches. That result describes package state, separate from agent health.

dpkg-query -W snmp snmpd

The terminal output was:

dpkg-query: no packages found matching snmp
dpkg-query: no packages found matching snmpd
[exit 1]

The recorded environment had no installed match for either package. On your host, keep this package result separate from the later service check because an absent client command and an inactive agent need different fixes.

Step 2: Install the client and agent

Install the client utilities and daemon together so the host can both answer a manager and run a local test. Package installation changes the system and requires an administrator account.

sudo apt update
sudo apt install snmp snmpd

Install both packages so this host has the client needed for a local check and the agent that answers remote queries. Red Hat family systems use different package names, so use that distribution’s package manager instead.

Step 3: Limit read-only access to the manager

Edit the packaged configuration at /etc/snmp/snmpd.conf. Remove any broad community rule and use the private addresses assigned to the agent and manager.

Some packaged configurations bind the agent to loopback for local queries only. The explicit agentaddress line adds the host’s private interface while keeping loopback for the local test. Binding every interface would expose the listener beyond the intended path.

agentaddress udp:127.0.0.1:161,udp:192.0.2.20:161
rocommunity <unique-random-community> 192.0.2.10
rocommunity <unique-random-community> 127.0.0.1

Replace 192.0.2.20 with the agent’s private IPv4 address. Set 192.0.2.10 to the manager’s source address, then replace the angle-bracket value with a unique community.

Use the same community on the manager. The first rule matches that manager, while the second permits the local test. These directive forms follow the Net-SNMP configuration manual.

Edit this file with administrator rights, then start the service. The command below enables the unit at boot and starts it now. It was left unrun because both actions need root and change system state.

sudo systemctl enable --now snmpd

If UFW is active, apply the rule below to the host firewall.

sudo ufw allow from 192.0.2.10 to any port 161 proto udp

That rule allows the example manager to send UDP traffic to port 161. It applies only to UFW, so check cloud or upstream firewalls separately. UDP has no connection handshake, so a dropped request can look like a timeout rather than a rejected connection.

Step 4: Query the agent from localhost

Check the service state before interpreting a failed walk. A successful localhost query confirms that the daemon answers on loopback with the version and community supplied to the client.

systemctl is-active snmpd
read -r -s -p "SNMP community: " SNMP_COMMUNITY
printf '\\n'
snmpwalk -v2c -c "$SNMP_COMMUNITY" 127.0.0.1 1.3.6.1.2.1.1
unset SNMP_COMMUNITY

Enter the configured community at the hidden prompt rather than putting a live value in shell history. A successful walk prints OIDs beside the values reported by the agent. This environment lacks the client package, and installing it needs root, so no walk output was captured here.

Step 5: Test from the monitoring manager

Run the same read-only query from the manager, changing the destination to the agent’s private address. Keep the same SNMP version and community that the agent allows.

read -r -s -p "SNMP community: " SNMP_COMMUNITY
printf '\\n'
snmpwalk -v2c -c "$SNMP_COMMUNITY" 192.0.2.20 1.3.6.1.2.1.1
unset SNMP_COMMUNITY

Use the agent’s private address in place of 192.0.2.20. If localhost answers but this query times out, inspect the listener and network path before changing the community.

Compare the source address reaching the agent with the allowed manager in the read-only rule, accounting for any NAT on the route.

Fix SNMP Linux Connection Problems

Use the symptom table to check the earliest failing layer because opening a firewall cannot fix a failed service. Confirm the service and listening socket first, then move outward to the host and network firewall.

Read the service journal when systemctl reports a failed unit. A restart can return without useful text, so the unit status and recent log entries give you the failure reason. Our Linux service control guide explains those checks.

A ping reply checks ICMP, not the SNMP listener. The ping guide explains that distinction. For socket details, see the Linux listening-port guide.

Check the host address and route with the Linux ip command guide, then review Ubuntu network configuration if an interface or route is wrong.

Conclusion: Keep SNMP Access Read-Only and Scoped

Keep the localhost result separate from the manager result because each tests a different part of the setup.

• Net-SNMP snmpd.conf manual for listener and access directive syntax.
• Debian snmpwalk manual for query options and OID traversal.
• Debian SNMP notes for package roles and distribution context.

FAQ

These answers cover common details that affect a first query.