Least-privilege SSH for third-party monitoring tools: the 10-line setup you should always do

You installed a monitoring tool. It asked for root. You said yes. Now a third party can run anything on your production box, forever.

Here's the setup that gives a monitoring tool what it needs — and nothing else.

1. Create a dedicated user

useradd -m -s /bin/bash monitorbot

2. Lock down its sudo to exact commands

Create /etc/sudoers.d/monitorbot:

monitorbot ALL=(ALL) NOPASSWD: /usr/bin/systemctl *, /usr/bin/journalctl *, /bin/df *, /usr/bin/free *

That's read-only system stats plus service control — the minimum a monitoring/repair tool needs. Note the trailing * on each: it allows arguments but no arbitrary command substitution.

3. Install a dedicated SSH key

mkdir -p /home/monitorbot/.ssh
echo "ssh-ed25519 AAAA... monitoring-tool-key" >> /home/monitorbot/.ssh/authorized_keys
chmod 700 /home/monitorbot/.ssh
chmod 600 /home/monitorbot/.ssh/authorized_keys
chown -R monitorbot:monitorbot /home/monitorbot/.ssh

4. Test the fence

sudo -u monitorbot sudo systemctl status nginx   # should work
sudo -u monitorbot sudo cat /etc/shadow          # should FAIL
sudo -u monitorbot sudo rm -rf /tmp/x            # should FAIL

If the second and third don't fail, your sudoers line is wrong — usually a missing full path (/bin/df, not df).

Bonus: audit what the tool actually does

journalctl _COMM=sudo -u monitorbot --since today

The principle

A monitoring tool needs to observe and, at most, restart known services. It does not need your files, your databases, or a shell that can do anything. Any vendor that demands root "for reliability" should be asked exactly which commands they run — and if they can't answer with a whitelist, that's your answer.

I build a monitoring tool and this is exactly the setup its installer creates — the fenced-user pattern above, verbatim. Use it for any vendor, including mine.