ssh-chat-mcp: SSH/SFTP для ИИ-агентов без конфигов и постоянных секретов

Это наш open-source MCP-проект AI Platforms под лицензией MIT: ssh-chat-mcp, zero-config MCP-сервер для временных SSH/SFTP-сессий. Публичный репозиторий лежит здесь: github.com/aiplatforms-ru/ssh-chat-mcp.

Когда ИИ-агенту нужно не просто ответить текстом, а реально зайти на сервер, проверить состояние, залить файлы, перезапустить сервис и выйти, обычного prompt-а уже недостаточно. Нужен инструментальный слой. Мы сделали этот сервер именно под такую задачу.

Мы разобрали код репозитория и посмотрели на него не как на красивую демку, а как на инженерный примитив: что хранится в памяти, что уходит в логи, как устроены команды, где границы безопасности и насколько проект готов к реальному использованию.

Что делает ssh-chat-mcp

По сути это MCP-сервер, который даёт модели временный доступ к удалённому Linux-хосту через SSH и SFTP. Сценарий простой:

• в чате пользователь передаёт host, username и временные креды;
• модель вызывает connect;
• дальше она может выполнять команды, читать и писать файлы, загружать директории и переключаться на другого пользователя через sudo;
• по завершении вызывается disconnect, и секреты стираются из памяти.

В наборе инструментов есть:

• connect и disconnect;
• list_connections;
• exec;
• exec_as;
• upload_file и upload_directory;
• download_file;
• read_remote_file и write_remote_file.

Это не просто SSH-обёртка. Это аккуратный слой между агентом и сервером, где каждое действие явно вызывается как tool, а не прячется в нечётком «пусть модель сама разберётся».

Почему это важно

У SSH-автоматизации обычно одна и та же боль: всё завязано на конфиги, inventory-файлы, переменные окружения и сохранённые ключи. Для стабильного production-хоста это иногда нормально. Для агентного сценария это уже не подходит.

ssh-chat-mcp делает ставку на другой режим:

• никакого предзаданного конфига;
• никакого хранения host-ов и ключей на диске;
• никакой миграции секретов между сессиями;
• всё живёт только в RAM и только на время соединения.

Это хорошо ложится на тот класс задач, где ИИ-агенту нужно действовать краткосрочно и под контролем пользователя: поднять сервис, проверить логи, залить конфиг, сделать точечный deploy, отработать инцидент и забыть про доступ.

Как устроен сервер

В коде это сделано довольно чисто.

src/index.ts регистрирует инструменты MCP, поднимает stdio transport и не пишет ничего в stdout до получения JSON-RPC. Это важная дисциплина: stdout здесь зарезервирован для протокола, а не для «красивых сообщений».

src/ssh/connectionManager.ts держит все соединения в in-memory Map. У каждого соединения есть статус, metadata и блок secrets. На disconnect секреты не просто забываются логически. На них вызывается очистка, а сам объект соединения удаляется из менеджера.

src/ssh/exec.ts отвечает за выполнение команд. Там есть:

• обычный exec;
• exec_as для запуска через sudo -iu;
• сбор stdout и stderr в буферы;
• таймаут с принудительным завершением канала;
• возврат exit code и signal;
• redaction выходных данных перед отправкой обратно в MCP-клиент.

src/ssh/sftp.ts закрывает файловые операции: upload, download, чтение, запись и рекурсивную загрузку директорий. SFTP используется напрямую, без внешних scp или rsync.

src/security/redact.ts и src/security/shellQuote.ts являются сердцевиной безопасности: redaction секретов, POSIX quoting, валидация Linux username и защита от shell injection в runAs.

Что в нём особенно хорошее

Есть несколько решений, которые в реальной эксплуатации важнее, чем выглядят на первый взгляд.

Первое: zero-config по-настоящему. Не «почти zero-config», а именно zero-config. Подключение живёт в чате, а не в отдельной конфигурации.

Второе: exec_as сделан не как магия, а как строго ограниченный путь через sudo -S -p '' -iu <runAs> -- bash -lc <command>. Это полезно, когда агент сначала работает от обычного пользователя, а потом должен выполнить привилегированный шаг вроде установки systemd-unit или nginx-конфига.

Третье: аккуратная работа с SFTP. В upload_directory есть исключения по basename, не следуются symlink-ы по умолчанию, а родительские директории создаются только когда это явно разрешено.

Четвёртое: redaction не декларативный, а практический. В коде и в тестах явно закрываются поля password, passphrase, privateKey, sudoPassword, token, apiKey, Authorization, secret, плюс PEM-блоки и распространённые text patterns вроде password= и Authorization: Bearer ....

Пятое: проект не полагается на ощущение безопасности. Он это проверяет. В репозитории есть тесты именно на redaction, quoting и ошибки, и они реально проходят.

Что показывает кодовый уровень качества

Мы прогнали npm test, npm run typecheck и npm run build. Всё собрано и проходит без ошибок.

В CI это тоже закреплено: GitHub Actions гоняет build-and-test на Ubuntu и Windows, под Node 20 и 22, а на Linux есть smoke-start, который проверяет, что сервер стартует молча и не пишет в stdout до входящих запросов.

Это маленькая, но показательная деталь. Для MCP-сервера молчание на старте не косметика, а часть протокольной корректности.

Безопасность и ограничения

Самое важное в этом проекте не скрыто, а честно зафиксировано в README и коде.

Первое ограничение: host-key checking выключен по дизайну. Это осознанная цена zero-config. Если сервер не хранит ничего на диске, то и классический TOFU-паттерн с known_hosts здесь не ложится без потери идеи.

Второе: destructive commands не блокируются на уровне самого сервера. Это тоже правильная инженерная позиция. ssh-chat-mcp не пытается изображать из себя песочницу. Ответственность за подтверждение опасных действий остаётся на стороне MCP-клиента и пользователя.

Третье: если вы передаёте пароль или приватный ключ в чат, они всё равно видны в транскрипте вашего клиента и могут логироваться провайдером модели. Для локальных или приватных клиентов это приемлемо. Для публичных облачных сценариев нужен особенно трезвый риск-менеджмент и, при необходимости, ротация кредов после сессии.

Четвёртое: это инструмент для точечных, временных операций, а не для долгоживущего fleet management. Если у вас классическая SSH-инфраструктура с inventory, постоянными хостами и строгим pinning-ом, этот сервер не заменяет Ansible или полноценный orchestration stack. Он закрывает другую задачу: быстро дать агенту контролируемый доступ в момент работы.

Практическая интеграция в агенты

Самая полезная часть этого проекта начинается там, где ssh-chat-mcp становится не отдельным инструментом, а частью agent loop.

Рабочая схема обычно выглядит так:

1. Агент сначала уточняет, на какой хост нужно зайти, под каким пользователем и с каким типом доступа.

2. Потом вызывает connect и получает временную сессию.

3. Дальше он проводит короткую разведку: list_connections, whoami, hostname, pwd, systemctl status, journalctl, ls, cat или read_remote_file.

4. Затем он делает точечное действие: загружает файл, пишет конфиг, запускает команду, переключается на exec_as для привилегированного шага.

5. После этого обязательно идёт проверка результата: тест конфига, проверка процесса, повторное чтение логов, статус сервиса, smoke-check.

6. В конце агент вызывает disconnect, даже если задача завершилась с ошибкой.

Для таких сценариев хорошо работает правило: один хост = один краткий цикл = один disconnect в конце. Не держите соединение дольше, чем нужно. Это дисциплинирует и модель, и оператора.

Есть и более конкретные паттерны:

• Для deploy-агента: upload_directory -> exec -> exec_as -> read_remote_file -> disconnect.
• Для incident-response агента: connect -> exec с диагностикой -> read_remote_file логов -> exec_as для правки конфигурации -> повторная проверка -> disconnect.
• Для infra-ассистента: временно залить systemd/nginx/cron конфиг в /tmp, потом безопасно перенести его sudo mv.

Важный практический момент: агенту не нужно «знать SSH». Ему нужно уметь пользоваться инструментами. ssh-chat-mcp как раз делает этот слой явным и контролируемым.

Если вы строите собственный агентный стек, этот сервер можно рассматривать как транспортный модуль для действий на удалённой машине. Подход к такому агентному слою мы уже разбирали в статье ИИ-агенты с tool-use: как модель сама ищет данные и добирает контекст.

Где это реально полезно

Самые сильные сценарии у такого MCP-сервера вполне приземлённые:

• временно зайти на новый сервер и проверить, что там всё поднялось;
• залить приложение, собрать его и перезапустить сервис;
• через write_remote_file подготовить systemd-unit или nginx-конфиг, а потом через sudo mv перенести его на место;
• отработать инцидент, прочитать логи, исправить конфиг и уйти;
• дать ИИ-агенту возможность не только советовать, но и действовать;
• использовать с локальными или приватными LLM-клиентами, где данные и команды не выходят из вашего периметра.

Почему этот репозиторий важен для AI Platforms

Для AI Platforms этот проект хорош не только как open-source релиз, но и как прикладной кирпичик в общей картине.

Мы строим частные LLM, RAG, агенты и on-prem AI. А значит, нам нужен не только умный ответ модели, но и надёжный способ действовать внутри чужой или своей инфраструктуры без лишнего credential sprawl. ssh-chat-mcp закрывает как раз этот промежуточный слой: агент понимает, что делать, и получает временный, ограниченный канал, чтобы это выполнить.

Это особенно полезно для on-prem контуров, где важно не уводить ничего в облако и при этом не обрастать вечными SSH-ключами, конфигами и ручными исключениями.

Вывод

ssh-chat-mcp это не просто SSH-сервер для MCP. Это аккуратный narrow-scope инструмент для ситуаций, где ИИ должен не только планировать, но и действовать на удалённой машине, причём делать это без сохранения секретов и без мусора в конфигурации.

Сильные стороны проекта: zero-config, in-memory connections, redaction, безопасный shell quoting, exec_as под sudo, SFTP-поток и нормальная тестовая дисциплина. Ограничения тоже честные: host-key checking off, нет blacklist-ов для опасных команд, нет попытки заменить полноценную SSH-автоматизацию общего назначения.

Именно такой баланс мы и считаем здоровым для агентных систем. Не обещать магию, а дать модели надёжный инструмент там, где он действительно нужен.