Published by Sascha Neumeier
Last updated on February 25, 2026
•
9 minute read
Installing SNMP is the first step when preparing your systems for SNMP Monitoring.
In this article I'll show you how to do that on Debian Linux.
As soon as this service is installed and configured, you can monitor system information like CPU load or memory usage on a Linux system using Paessler PRTG.
Enabling SNMP on Debian Linux
If you manage Linux servers, you've probably run into this situation at least once: you set up a new monitoring tool, point it at a Linux host - and nothing. No data. The reason is almost always the same: the SNMP daemon isn't installed, or the SNMP configuration is incomplete. Let's fix that.
The steps below describe a basic but functional approach to configuring SNMP on Debian Linux. This setup gives you unrestricted read-only access to ALL SNMP metrics available on the host. Quick heads-up though: if your device is publicly reachable on the Internet, you should definitely use a stricter configuration - or look into SNMPv3, which includes encryption and authentication support. For the full details, check the official snmpd.conf documentation.
1. Prerequisites
Before anything else: all the following commands need root access. Depending on how your Debian system is set up, you either switch to root with su - first, or you prepend sudo to every command. The examples below assume you're already running as root - adjust accordingly if you're not.
2. Install SNMP - the SNMP Daemon
Let's install SNMP. One command is all it takes:
apt-get install snmpd
That's it. apt-get pulls in the net-snmp package and everything it depends on. If you're on Ubuntu, the command is identical - no changes needed. On Red Hat-based distributions like CentOS or RHEL, the package manager is different, so you'd run yum install net-snmp net-snmp-utils there instead.
One more thing while you're at it: consider installing the snmp-mibs-downloader package as well. It's not strictly required, but it makes your life a lot easier later when you're reading snmpwalk output. Without MIB files, everything shows up as raw numeric OIDs - which is readable, technically, but not exactly pleasant. More on this in step 5.
3. Create a Backup of the SNMP Configuration File
After installation, the snmpd.conf file lands at /etc/snmp/snmpd.conf. Before you change a single line in that configuration file, make a backup:
cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.orig
Yes, this is obvious. And yet - it's one of those things people skip when they're in a hurry, and then regret 45 minutes later when they're staring at a broken config with no idea what the original looked like. Just do it.
🚀 Want to monitor your Linux systems with PRTG right away?
👉 Download your free trial now and get started in minutes.
4. Adjust the Configuration
Now open /etc/snmp/snmpd.conf in your editor of choice. The default file that comes with the package is... let's call it verbose. For a clean, minimal setup, the easiest approach is to comment out or delete everything that's already in there and replace it with just the following lines:
# IPv4 setup
agentaddress udp:161
rocommunity public 0.0.0.0/0
# IPv6 setup
agentaddress udp6:161
rocommunity6 public ::/0
If you're not running IPv6, leave that second block out. No harm done.
So what does this actually do? The agentaddress udp:161 line tells the SNMP daemon to listen on UDP port 161 across all IPv4 network interfaces. Port 161 over UDP is the default for SNMP - that's what Paessler PRTG and pretty much every other monitoring tool will try first.
The rocommunity public line sets up a read-only community string named "public". You'll see this community string everywhere - it's the default on countless routers, switches, and Linux systems. The 0.0.0.0/0 means any IP address can query it. For a lab or an isolated internal network, that's fine. In production, you'd want to lock that down to a specific IP address or at least a subnet, especially if there's a firewall between your monitoring server and this host.
Why rocommunity and not rwcommunity? SNMP v1 and SNMP v2c send everything in plain text - no matter which SNMP version you use within that range. If someone's sniffing your network, they can read the community string. If that string has write access, they can potentially modify things on your system. Read-only only. No exceptions.
Genuinely concerned about security? Switch to SNMPv3. It actually supports authentication and encryption, unlike its predecessors. There are three security levels: noauth (no authentication, no privacy - essentially the same risk as v1/v2c), authnopriv (authenticated but unencrypted), and authpriv (authenticated and encrypted). For anything production-facing, authpriv is the only reasonable choice.
5. Save Changes and Restart the snmpd Service
Save the file. Then restart the snmpd service to apply the new configuration:
service snmpd restart
On newer Debian and Ubuntu systems, systemctl works just as well:
systemctl restart snmpd
That's it - the basic setup is done. Your linux system is now ready to respond to SNMP queries.
Want to confirm it's actually working? Run this from the same machine:
snmpwalk -v2c -c public localhost
If you get back a stream of data - OIDs, TimeTicks values, sysLocation, sysContact entries - the SNMP service is running correctly. Good to go.
One thing you might notice: the output is full of raw numeric OIDs instead of readable names. That's because the snmp-mib files aren't installed. Fix it by installing snmp-mibs-downloader and then opening /etc/snmp/snmp.conf - find the line that says mibs : and comment it out by adding a # in front. After a restart, snmpwalk will show proper MIB names instead of number strings.
If snmpwalk times out completely or returns nothing at all, work through these checks:
- Firewall first. iptables or another firewall blocking UDP port 161 is the single most common reason SNMP doesn't respond. SNMP runs over UDP by default - though TCP is also supported if you add
agentaddress tcp:161to your config. - Enable debug output. Add the
-dflag:snmpwalk -d -v2c -c public localhost. This prints a hex dump of what's being sent and received, which makes it much easier to see where things break down. - Check the syslog.
journalctl -u snmpdorgrep snmpd /var/log/syslogwill usually tell you exactly what the daemon is complaining about. Misconfigured lines in snmpd.conf often show up here.
For more details on how to set up SNMP on Linux, check our Paessler Knowledge Base 👉 Checklist – Setting up SNMP on Linux.
To configure SNMP for other Linux distributions, don't miss our article 👉 How to enable SNMP on your operating system
Monitor Entire Processes in Linux
Once SNMP is running, it doesn't take long before CPU and memory data just aren't enough anymore. You want to know if a specific process is still alive. You want thresholds. You want notifications at 2am when something crashes - ideally before your users notice. If that sounds familiar, we've written an article that walks you through exactly that: how to monitor processes under Linux. Check it out in the Paessler Knowledge Base 👉 Monitoring processes in Linux.
Native Linux Monitoring with the PRTG Multi-Platform Probe
For a long time, one of the more common complaints about PRTG was this: why does the probe need to run on Windows? If you were managing a Linux-heavy environment, that meant keeping a Windows machine around just to run monitoring infrastructure. Not ideal.
That changed in November 2024. Paessler announced the general availability of the Multi-Platform Probe for PRTG - stable, production-ready, no asterisks. It's been a while coming, but it's here.
In practice, this means you can now run a PRTG probe directly on Debian, Ubuntu, or Red Hat Enterprise Linux (RHEL), without a Windows host in the middle. If you're on PRTG Hosted Monitor, you can run the whole thing in a completely Windows-free setup. For anyone monitoring remote locations or subnets separated by firewalls, this is particularly useful - spinning up a lightweight Linux probe in a remote office is a lot more practical than provisioning a Windows server just for monitoring.
The probe communicates over TLS 1.3, so data in transit is encrypted. Sensor support covers ICMP, SNMP, HTTP, and REST out of the box, and the functionality keeps expanding with each release. PRTG also includes pre-built sensor templates for common Linux monitoring scenarios - CPU load, memory usage, network interfaces, process status - so you're not starting from zero.
Supported platforms:
- Debian, Ubuntu, and Red Hat Enterprise Linux (RHEL)
- Docker and Windows
- ARM-based devices - Raspberry Pi, other single-board computers, NAS systems
For installation, skip the older Knowledge Base articles (they're archived) and go straight to the official manual: Multi-Platform Probe for PRTG. It's the most current source and covers everything from prerequisites to the actual setup steps.
A few other useful starting points:
- ✔️ First steps with the new Paessler PRTG Multi-Platform Probe
- ✔️ What is the Multi-Platform Probe and how can I use it?
- ✔️ Step-by-step installation guide for the Multi-Platform Probe
🔥 Ready to take your Linux monitoring to the next level?
👉 Download PRTG for free and see what's possible - no credit card required.
You there!
