Linux MCP daemon (mcpd) — это сервер на Go, который отдаёт ИИ-агенту состояние Linux-системы через инструменты Model Context Protocol. Сейчас их 38, и список растёт. Агент не получает SSH-доступ и не работает под sudo: он вызывает инструменты, а mcpd читает данные напрямую из /proc, /sys и из systemd по D-Bus.
Отправная точка проекта практическая. При разборе инцидентов автор всё чаще использует ИИ-агента: тот собирает информацию о сервере (нагрузку, память, диски, процессы, журналы) и сводит её с данными мониторинга, чтобы понять, почему тормозит сайт, чем забит диск или что упало ночью. Раньше для этого пришлось бы выдать агенту SSH с sudo, и автор считал такой путь не самым безопасным. Формулировка из его описания проекта звучит так:
Я захотел, чтобы агент видел сервер через набор понятных инструментов, root получал только на то, что я разрешил, и чтобы каждый его шаг был записан.
Из этого требования выросли три вещи: сам демон mcpd, конфиг с границами прав для отдельных инструментов и клиент linuxctl для работы с операционной системой как с деревом объектов. Первоисточники, на которые опирается разбор: статья автора проекта на Хабре и репозиторий linux-mcp-daemon на GitHub.
Что такое Linux MCP daemon и зачем он нужен
mcpd не оборачивает стандартные утилиты и не запускает их от имени агента. Он сам читает состояние системы из ядра и отдаёт его агенту через инструменты. Протокол, на котором всё построено, описан отдельно: MCP как универсальный протокол подключения ИИ-агентов к внешним инструментам. Если вы уже знакомы с MCP, дальше можно смотреть только на реализацию.
Какую задачу решает mcpd
Типовой сценарий: ночью упал сервис, вы открываете агента и просите разобраться. Агент через mcpd смотрит загрузку ядра, потребление памяти, заполненность дисков, список процессов, состояние юнитов systemd и журналы, после чего сопоставляет это с данными мониторинга. Все эти данные приходят структурированными, а не в виде текста, который нужно парсить глазами и объяснять модели заново в каждом запросе.
Ключевая разница с привычной схемой: агенту не нужна интерактивная оболочка на сервере. Он видит ограниченный, заранее описанный набор инструментов, и каждый вызов оставляет след.
Чем mcpd отличается от обёрток над утилитами
Большинство MCP-серверов для Linux устроены как прослойка: возьми команду вроде ls, ps или df, выполни её и верни stdout агенту. mcpd так не работает. Он читает /proc, /sys и systemd по D-Bus, то есть работает с первоисточником данных, а не с человекочитаемым выводом поверх него. Внешние программы вызываются только там, где своя реализация была бы хуже, и запускаются без shell, с отдельными аргументами.
Практические следствия: ответы не ломаются от версии coreutils, локали или нестандартного форматирования, а набор полей предсказуем. Число инструментов не фиксировано: на момент публикации их 38, и автор отмечает, что список продолжает расти.
Почему SSH с sudo — не лучший путь для ИИ-агента
Существующие способы подключить Linux-сервер к агенту автор делит на три типа, и у каждого свои ограничения. Классификацию и примеры он приводит в исходной публикации.
Удалённый shell под соусом MCP: где ломается белый список
Самый популярный вариант: инструмент «выполнить команду» плюс белый список разрешённых команд. Так устроены, например, ssh-mcp и десятки его форков. Слабое место архитектурное, а не в качестве кода: белый список обычно проверяет только первое слово команды, а вся строка целиком уходит в sh -c. Запись ls; rm -rf ~ начинается с разрешённого ls и проходит проверку. Разделители, конвейеры и подстановки остаются в распоряжении модели.
Оговорка: это описание проблемы в общем виде, без разбора конкретного исходного кода ssh-mcp или отчёта об уязвимости. Если вы выбираете такое решение, проверяйте реализацию белого списка в конкретном форке самостоятельно.
Только чтение: безопасно, но бесполезно для действий
Второй тип даёт агенту десятки инструментов для диагностики, в том числе на удалённых хостах по SSH. Пример такого подхода — linux-mcp-server от Red Hat: MCP-сервер для read-only администрирования, диагностики и траблшутинга Linux-систем на базе RHEL, где все инструменты строго read-only. Он умеет выполнять команды на удалённых системах по SSH с аутентификацией по ключу и подключаться к разным удалённым хостам в одной сессии. Сломать что-то через него сложно, зато и починить нельзя: только посмотреть. Отдельная проблема в том, что доступ к хосту всё равно выдаётся SSH-ключом на весь аккаунт, а значит границ на уровне отдельных инструментов там не появляется.
SSH напрямую: агент получает всё, что может аккаунт
Третий тип самый простой в настройке и самый широкий по правам. Агент получает всё, что может аккаунт, а с sudo — и root. Точечной выдачи прав по инструментам нет, встроенного аудита действий тоже. Автор не нашёл среди найденных решений того, что ему было нужно, и собрал собственный вариант.
Архитектура mcpd: инструменты, процессы и точечный root
Сервер написан на Go и работает как обычный MCP-сервер: агент подключается к нему и видит список из 38 инструментов. Источники данных три: /proc, /sys и systemd по D-Bus. Парсинга вывода консольных утилит нет, поэтому формат ответа стабилен. Проект реализует философию zero-dependency (kernel-first): взаимодействие с хост-системой идёт напрямую через raw syscalls и Virtual File System, без сторонних библиотек парсинга. Это один статический Go-бинарник, который работает на bare host, в Docker или в Kubernetes.
Агент не выполняет команды: он вызывает инструменты с понятными именами, а для каждого инструмента сервер выдаёт описание и JSON-схему аргументов, так что агент сам понимает, что умеет сервер.
Как mcp-sudo.yaml ограничивает root-доступ
Когда агенту нужен root, он может его запросить, но получит только там, где это разрешено, и в заданных границах. Границы описываются в конфиге mcp-sudo.yaml, отдельно для каждого пользователя и инструмента. В файле для каждого пользователя перечислено, какие инструменты он может вызвать с privileged: true, то есть от root, и в каких пределах. Для инструментов с путями указывается ключ paths, например paths: [/var/log] означает root только внутри /var/log. Ключ deny_private: true закрывает обращения к приватным адресам: localhost, 10/8, 169.254.169.254. Это принципиально другая модель, чем SSH с sudo: права выдаются не на весь аккаунт, а на конкретную операцию конкретного инструмента.
Оговорка по деталям: в доступных фрагментах привязка deny_private именно к инструменту network/curl прямо не указана, а полный перечень ключей конфига раскрыт не полностью. Синтаксис и актуальный список параметров стоит сверять в репозитории проекта, прежде чем переносить примеры в свою конфигурацию.
Почему каждый вызов — отдельный процесс
Каждый вызов выполняется отдельным процессом от имени соответствующего Linux-пользователя. Долгоживущей сессии с накопленными привилегиями нет: следующий вызов стартует с чистого состояния. Это ограничивает последствия одной неудачной операции и упрощает разбор того, что именно сделал агент.
Важно не переоценивать эту изоляцию. Отдельный процесс — это не полноценная песочница: он выполняется в обычном окружении системы, а реальные границы задаёт конфиг и права пользователя, от имени которого процесс запущен.
Установка mcpd и подключение ИИ-агента
mcpd — это открытый проект, поэтому установка сводится к получению бинарника на целевом сервере и настройке конфига. Конкретные команды, версии и формат файлов здесь не приводятся: их нужно брать из репозитория проекта, чтобы не расходиться с текущим состоянием кода. Логика шагов при этом предсказуема.
Настройка mcp-sudo.yaml под свои задачи
Начинать стоит с минимального набора инструментов, которые агенту действительно нужны, и расширять его по мере появления задач. Для чтения файлов задайте paths с конкретными каталогами вместо всей файловой системы. Для инструментов, ходящих по сети, включайте deny_private, чтобы агент не обращался к приватным адресам. Выдавать root на всё сразу не нужно: смысл конфига в том, чтобы каждая новая привилегия появлялась осознанно и отдельно.
Проверьте, какие инструменты агент вызывает на практике. Если половина списка не используется, они остаются лишней поверхностью атаки.
Подключение агента к MCP-серверу
Для агента mcpd выглядит как обычный MCP-сервер: он подключается, получает список из 38 инструментов и вызывает их по мере необходимости. Механика такого подключения, включая обнаружение инструментов и корреляцию запросов, разобрана в материале про MCP-мост между облачным агентом и локальной машиной. Конкретные клиенты здесь не перечисляются: выбор зависит от того, чем вы уже пользуетесь.
linuxctl: управление ОС как деревом объектов
Отдельная часть проекта — утилита linuxctl, сделанная в стиле kubectl. Мотивация автора простая: из-за большой любви к Kubernetes и его объектной модели ему захотелось так же управлять операционной системой, то есть представить её как дерево объектов (процессы, диски, сервисы, файлы) и работать с ними привычными командами. Об этом он рассказывает в той же публикации о проекте.
get и describe: как выглядит работа с объектами
get возвращает объект или список объектов, describe показывает подробности по конкретному. Если вы работали с kubectl, модель считывается сразу: вместо запоминания десятка утилит и их флагов вы работаете с сущностями системы однотипно. Для агента это тоже удобнее: структура команд предсказуема, а значит меньше шансов на неожиданный вызов.
create и delete: когда нужны изменяющие команды
create и delete меняют состояние системы, и именно здесь важно, чтобы ограничения из mcp-sudo.yaml были настроены заранее. linuxctl не обходит границы mcpd: это клиент для работы с операционной системой, а не отдельный канал с расширенными правами. Воспринимайте изменяющие команды как операции, которые требуют явного разрешения, а не как бонус к диагностике.
Риски и грабли mcpd: что нужно знать до установки
Запись в /etc, сервисы и чтение всего диска
В описании проекта прямо перечислены возможности, которые фактически дают полный root: запись в /etc, управление сервисами, чтение всего диска и участие в группе docker. Разберём, почему каждая из них критична.
- Запись в
/etcпозволяет править конфигурацию системы и служб, включая те, что запускаются от root. - Управление сервисами даёт запуск и остановку юнитов, а значит и запуск произвольного кода в рамках существующих служб.
- Чтение всего диска открывает доступ к секретам, ключам и базам данных, даже если приложение их не отдаёт.
- Группа
dockerпозволяет поднять контейнер с примонтированным корнем хоста, что равносильно полному root. Любой член этой группы может запускать контейнеры, а команда видаdocker run -v /:/host <образ>даёт полный доступ к корневой файловой системе хоста. Docker при этом запускает контейнеры от root, даже если не указывать этого явно, поэтому доступ к сокету Docker по сути эквивалентен полномочиям sudo-пользователя на хосте.
Вывод простой: границы в mcp-sudo.yaml нужно настраивать осознанно, а не выдавать всё сразу ради удобства.
Симлинки, root в mcpd и путаница с privileged
Отдельный класс проблем связан с тем, как ограничения реализованы. Симлинк может указывать за пределы разрешённого paths, поэтому проверка пути без учёта ссылок ничего не гарантирует. Пользователь root в mcpd создаёт свою головную боль: если процесс работает от root, точечные границы теряют часть смысла.
Про путаницу с privileged честная оговорка: в доступных материалах подтверждено только то, что в mcp-sudo.yaml есть аргумент privileged: true, означающий вызов инструмента от root. Утверждение о различии между флагом Docker --privileged и этим аргументом ни одним фрагментом не подтверждено, поэтому не стоит считать их взаимозаменяемыми или, наоборот, путать без проверки документации Docker.
Эти грабли особенно важны для тех, кто ставит mcpd на продакшен. На домашнем сервере цена ошибки ниже, на боевой машине она может выражаться в компрометации всего хоста.
Кому подходит mcpd и когда лучше не использовать
Когда mcpd даёт выигрыш
Разбор инцидентов, регулярная диагностика, автоматизация рутинных проверок, домашний AI-сервер с агентом. Выигрыш в трёх вещах: root выдаётся точечно, набор доступных действий описан заранее, а каждый вызов можно разобрать постфактум. Для сценариев, где агенту нужно не только смотреть, но и действовать, это более управляемая модель, чем SSH с sudo.
Когда лучше выбрать другое решение
Если агенту нужен только мониторинг, read-only решения вроде linux-mcp-server от Red Hat проще: меньше настроек и меньше риска. Если нужен полный контроль без ограничений, прямой SSH с sudo остаётся вариантом, но тогда все риски ложатся на вас целиком. mcpd не отменяет необходимость думать о безопасности: запись в /etc, управление сервисами, чтение всего диска и группа docker фактически дают полный root, и никакой конфиг это не изменит, если выдать их агенту.
Тренд на то, что агент становится интерфейсом к инфраструктуре, а не дополнением к ней, разобран в материале про MCP как новый интерфейс продукта. Чем больше действий доступно агенту, тем важнее заранее очертить их границы.
Что дальше: развитие проекта и практические выводы
Проект открытый, список инструментов растёт, а значит конфигурацию придётся периодически пересматривать: новые инструменты по умолчанию добавляют новые возможности. Что сделать перед запуском:
- Соберите бинарник из репозитория и запустите mcpd на тестовой машине, а не сразу на боевом сервере.
- Задайте в
mcp-sudo.yamlминимальный набор инструментов:pathsдля инструментов с путями,deny_privateдля сетевых обращений, ничего лишнего. - Проверьте поведение на симлинках и убедитесь, что процесс не работает от пользователя root.
- Не выдавайте агенту то, что фактически даёт полный root: запись в
/etc, управление сервисами, чтение всего диска и группуdocker. - Включите логирование вызовов и время от времени просматривайте, что агент делал на самом деле.
mcpd решает конкретную задачу: дать агенту понятные инструменты вместо SSH-сессии и ограничить root там, где это возможно. Решение не отменяет аккуратности в правах, зато делает эту аккуратность настраиваемой и проверяемой.