SSH-инструмент для ИИ-агента через MCP может дать агенту доступ к заранее определённым командам на удалённой машине. Для этого собирают собственный MCP-инструмент с отдельной учётной записью, серверной проверкой параметров и журналом вызовов. Перед рабочим доступом его испытывают на тестовом сервере. Здесь разбираем именно SSH-доступ — общие MCP-серверы и браузерные инструменты разобраны в соседних материалах. Контур работает, когда список команд и границы допуска описаны заранее.
Зачем агенту SSH
Начните с чтения статуса службы через одну именованную операцию. Время настройки измеряйте после проверки прав, отказов, журнала и восстановления доступа: эти этапы зависят от вашей инфраструктуры.
Агенту без инструментов остаются советы. С SSH-инструментом через MCP он может проверить статус службы и выбранные журналы. Перезапуск добавляют как отдельную операцию после тестов и проверки подтверждения. MCP здесь — протокол подключения инструментов: агент видит описание команды и вызывает её через единый интерфейс, а обвязку безопасности держит ваш сервер.
Общая механика собственного MCP-сервера разобрана в статье про свои инструменты для агентов — здесь фокус узкий: один SSH-инструмент с жёсткими границами. Браузерные инструменты вроде управления страницей — соседняя дорожка, под неё отдельные материалы.
- Чтение: статус служб, логи, свободное место на диске.
- Обслуживание: отдельно разрешённый перезапуск конкретной службы после подтверждения.
- Диагностика: проверка портов, нагрузки, последних изменений.
- Изменяющие действия: отдельная проверка прав, параметров и подтверждения.
Цепочка вызова прямая: агент получает поручение «проверь, почему лежит сайт», выбирает инструмент, обёртка выполняет разрешённые команды диагностики, агент читает вывод и отвечает в чат с выводом и предложением. Человеку показывают проверяемый итог и нужный фрагмент вывода. Перед передачей текста модели и в чат удаляют секреты и персональные данные из логов.
Границы доступа
Первое правило — отдельная учётная запись на сервере, созданная только для агента. Её права ограничивают нужными файлами и службами. Ключ хранится в защищённом хранилище со стороны MCP-сервера. Агент вызывает именованную операцию с проверенными параметрами; выполнение произвольной строки shell запрещают. На стороне SSH можно закрепить принудительную команду или ограничения ключа, чтобы обход обёртки тоже давал отказ.
- Учётная запись: отдельный пользователь, ключ в хранилище, минимальные системные права.
- Белый список: именованные операции с проверкой аргументов без передачи строки в shell.
- Чтение и запись: разные команды, разные подтверждения.
- Сессии: ограниченные по времени; журнал хранит нужные параметры и очищенный от секретов результат.
Второе правило — чтение и запись идут разными дорожками. Даже чтение требует проверки: журналы могут содержать токены, адреса и персональные данные. Разрешайте конкретные источники и очищайте вывод. Команды изменения требуют подтверждения уполномоченного человека. Сервер сверяет личность подтвердившего, точные параметры команды и срок действия запроса; результат попадает в журнал.
Ключи живут по правилу минимума: отдельный ключ для инструмента, защищённое хранение, минимальные права и запрет ненужного перенаправления. При необходимости sudo разрешают только для конкретной операции с отдельной проверкой. При компрометации агентского ключа инженер отзывает один ключ, а доступ людей и смежных сервисов остаётся нетронутым. Порядок ротации и отзыва ключа проверяйте на тестовом сервере до запуска.
Порядок сборки
- Создайте отдельную учётную запись на тестовом сервере, храните ключ защищённо и ограничьте доступ по сети, если ваша инфраструктура это позволяет.
- Опишите команды обёрткой. Каждая разрешённая операция — именованная команда с фиксированным шаблоном параметров, произвольный shell закрыт серверной проверкой и SSH-ограничениями.
- Опишите инструмент для MCP. Название, назначение, параметры и границы — чтобы агент видел ровно то, что разрешено.
- Подключите подтверждения. Для изменяющей операции сервер показывает подтверждающему точную команду и проверяет его ответ.
- Заведите журнал. Каждый вызов: инициатор, операция, проверенные параметры, время и очищенный результат.
- Прогоните фикстуру. Тестовый сервер со сценариями отказов — прежде боевого доступа.
Добавление новой операции требует прав на SSH-сервере, проверки аргументов, теста отказа и обновления описания MCP-инструмента. Срок зависит от этих согласований.
Описание инструмента держите в формате, понятном агенту: что делает команда, какие параметры принимает, какой вывод давать и когда просить подтверждение. Чем точнее описание, тем реже агент ошибается с выбором — подробности про этот формат разобраны в материале про описание инструментов MCP.
Чем короче список команд, тем предсказуемее поведение агента — и тем спокойнее аудит.
Какие команды на ваших серверах агенту нужны в первую очередь?
Подтверждение и журнал
| Команда | Подтверждение | Кто подтверждает |
|---|---|---|
| Логи и статусы | По роли и регламенту | — |
| Перезапуск службы | Кнопка в чате | Дежурный инженер |
| Изменение конфигурации | Отдельное разрешение | Дежурный инженер |
| Остановка или удаление | Отдельное разрешение | Руководитель инфраструктуры |
Для устойчивого аудита журнал размещают отдельно от управляемого сервера. В него передают очищенный вывод: полный текст системных логов может содержать секреты. По журналу ищут ошибки выбора операции и повторяющиеся отказы. Расширение списка команд утверждает владелец инфраструктуры после отдельного теста.
Узкий набор операций упрощает проверку каждого вызова и его последствий. из внутреннего регламента доступа
При инциденте журнал становится главным свидетелем: восстанавливается цепочка «поручение — команда — вывод — подтверждение», видно, какое действие привело к простою и чьё подтверждение его сопровождало. Разбор завершается проверяемой правкой: уточните разрешения, описание инструмента и тестовую фикстуру, затем повторите испытание.
Тест на фикстуре
Начните с одной команды чтения на тестовом сервере. Отмечайте ошибочные вызовы, отказы и случаи, когда вывод требует ручной проверки. Полный shell для эксперимента опасен: проверьте отказ на произвольной команде прежде доступа к рабочему серверу.
Фикстура — тестовый сервер со сценариями разрешённого чтения, ошибочной команды и отказа в доступе. Отдельно проверьте строку в логе, которая просит агента выполнить действие: содержимое лога остаётся данными. Перед боевым доступом агента прогоняют по фикстуре: правильные диагностики, верные предложения действий, честные «нет данных» взамен выдуманных выводов. Сценарии фикстуры расширяют по мере разборов журнала — каждый реальный промах агента превращается в новый тест, который контур обязан проходить до следующего боевого вызова.
Экономика контура складывается из времени инженера на обвязку и расхода токенов модели. Условия тарификации выбранной модели меняются; расходы считайте по фактическим запросам и времени сопровождения. Настройку SSH-инструмента и обвязки безопасности можно отдать подрядчику: логику цены и состав работ описываем на странице про ИИ-агентов для бизнеса.
Раз в месяц журнал разбирают с инженером: какие команды просили чаще, где агент ошибался, что добавить в фикстуру. Такой разбор держит контур живым: белый список растёт по факту потребности, подтверждения ужесточаются там, где агент ошибался.
Регламент доступа обновляют при изменении команд и ответственных: кто владеет учётной записью, кто подтверждает опасные команды, как происходит отзыв ключа и добавление новой команды. Держите его рядом с журналом: новый инженер поднимает контур по документу, а аудит проходит без расспросов команды.