Handing your server over to an AI agent: linux-mcp-daemon instead of SSH with sudo

⚡ The gist in 5 seconds - The point: the author created linux-mcp-daemon (mcpd) and a client called linuxctl — a combo that lets an AI agent manage a Linux server via MCP without SSH or sudo. - Availability: the daemon is written in Go and builds into a single static binary; the article describes getting it running in a couple of minutes and connecting it to an agent. - Limitation: root is granted only for specific tools and with explicit boundaries; without paths in mcp-sudo.yaml the config won't load. ### 🔍 What was found The author reviews existing MCP solutions for managing Linux and identifies three types: a remote shell wrapped in MCP (ssh-mcp and forks), read-only tools like Red Hat's linux-mcp-server, and plain SSH. The first type only gives an illusion of control: the whitelist checks only the first word, and the command is passed to sh -c, so ls; rm -rf ~ gets through. An advanced fork by t11z classifies commands, asks for confirmation, and keeps an audit log, but at its core it's still text parsing. The Red Hat option is safe but works only for reading. So the author built their own tool: the mcpd daemon and the linuxctl client. mcpd works over MCP on top of JSON-RPC, lives on the server, and the agent talks to it over HTTPS. The daemon has 38 tools and 11 persistent resources plus 6 templates. Most data is read directly from /proc, /sys, and systemd via D-Bus, rather than parsing the output of ps, df, or systemctl. External programs — smartctl, traceroute, journalctl, dmesg, last, find — are run without a shell, with separate arguments. Each call is executed by a separate worker process running as the Linux user corresponding to the mcpd user. TLS is enabled by default. The author also points out a vulnerability in the stdio transport demonstrated by OX Security in April: the client executes a command from the config to start the server, and a tampered config can run someone else's code. mcpd doesn't have this problem: the client doesn't launch anything locally, and no official SDKs are used. ### 💡 Why it matters The idea is to give the agent not a shell, but a set of well-defined tools with JSON schemas for arguments. The agent decides what to call, and root privileges are granted surgically. In mcp-sudo.yaml, for a user you can allow files/read as root only in /var/log: without paths, the config won't load. For network/curl there's deny_private: true — the agent won't be able to reach localhost, 10/8, or 169.254.169.254. This cuts incident triage time: the agent quickly gathers load, memory, disks, processes, and logs, correlates them with monitoring, and can restart a service or change a config on its own — but only within the allowed boundaries. ### 🧩 Context The author is a practitioner who increasingly uses an AI agent to collect data from servers during incidents. Giving such an agent SSH with sudo seems unsafe to them, so they wanted to manage the operating system as a tree of objects — processes, disks, services, files — with commands in the spirit of Kubernetes get and describe. That's how linuxctl and linux-mcp-daemon came about. The article's title promises: hand your server to an agent and have no regrets.

🔗 Read on habr.com