SSH MCP Server — инструменты удалённого сервера для ИИ-агентов

Он использует уже установленный на вашей машине OpenSSH-клиент: ваши ключи, ваш ~/.ssh/config, ваши jump-хосты, проброс вашего агента. Ничего встроенного, ничего компилировать, никаких нативных привязок.

Работает с Claude Code, Codex CLI, opencode, Gemini CLI, Qwen Code, Hermes и другими MCP-клиентами.

Установка · Инструменты · Настройка · Безопасность · Дорожная карта · Документация · Журнал изменений

Установка за 30 секунд

Глобальная установка не требуется. npx загружает пакет при первом использовании:

npx -y @hypnosis/ssh-mcp-server

Добавьте его в Claude Code для каждого проекта:

claude mcp add ssh -s user \
  -e SSH_PROFILES_FILE="$HOME/.claude/ssh-profiles.json" \
  -- npx -y @hypnosis/ssh-mcp-server

Затем создайте ~/.claude/ssh-profiles.json хотя бы с одной машиной:

{
  "profiles": {
    "production": {
      "host": "server.example.com",
      "username": "admin",
      "privateKeyPath": "~/.ssh/your_private_key"
    }
  }
}

Этого достаточно для подключения.

Codex, opencode, Qwen Code и другие клиенты описаны в разделе Настройка SSH MCP сервера.

Требования

Node.js 18+ и системный ssh-клиент в PATH. В Windows используйте профиль на основе ключей; профили с паролем и парольной фразой сейчас недоступны.

Предпочитаете закреплённую версию, офлайн-работу или меньше проверок реестра при каждом запуске: npm install -g @hypnosis/ssh-mcp-server, затем используйте ssh-mcp-server как команду вместо npx.

Related MCP server: ssh-mcp-server

Для кого это

• DevOps и SRE — для тех, кто хочет быстрее проводить аудиты, проверки инцидентов и рутинную работу с серверами.

• Vibe-кодеры и инди-разработчики — для тех, кто выпускает продукты с ИИ-ассистентом и запускает созданное на собственных серверах.

• Системные администраторы и платформенные инженеры — для тех, кому нужны структурированные инструменты вместо неограниченной сырой оболочки.

• Разработчики и небольшие команды, управляющие собственным VPS без выделенной команды эксплуатации.

• Владельцы домашних серверов, NAS и роутеров, чьё полезное железо пережило свои современные протоколы.

Почему SSH MCP сервер, а не сырая оболочка

Меньше токенов, ниже расходы на ИИ

Сырая оболочка даёт ИИ-агенту поток данных: повторяющиеся команды, ASCII-таблицы и дампы логов. На превращение этого шума в картину состояния сервера тратятся токены — ваши деньги.

Более быстрая отладка сервера

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

Меньше догадок, меньше ошибок ИИ

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

Совместимость SSH: современные серверы, устаревшее оборудование и Windows

Используйте свою существующую настройку OpenSSH

Никакой встроенной реализации SSH, никаких нативных привязок, никакой пересборки под каждую платформу. Команды используют системный ssh-клиент, поэтому ваши ключи, ваш ~/.ssh/config, ваши jump-хосты и проброс агента работают точно так же, как в терминале. Если поддерживается, одно общее мультиплексированное соединение на адресата означает, что вы аутентифицируетесь один раз, а не при каждой команде.

Поддержка SSH для устаревших серверов, роутеров и NAS-устройств

Отправьте файл на роутер с помощью современного scp — и получите вот это:

scp app.conf router:/etc/
# scp: subsystem request failed on channel 0

Ничего не сломано — современный scp говорит на новом протоколе, а роутер его не знает. В терминале вам пришлось бы читать ветку на форуме и возвращаться с дополнительным флагом. Здесь вы ничего не делаете: передача пробуется, отказ распознаётся, вместо него используется старый протокол, и эта машина запоминается, так что следующий файл уходит сразу туда.

Запасные варианты для старых SSH-клиентов и отсутствующих инструментов

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

Создан для Model Context Protocol

Построен на официальном MCP SDK, полностью на TypeScript, 2500+ модульных тестов плюс живой набор тестов, который запускается на реальных контейнерах, а не на заглушках.

Сырой SSH против SSH MCP сервера: одна и та же задача, оба подхода

Проверка состояния SSH-сервера

Ситуация: Только что прошёл деплой. Сервер работает медленно, и вы не знаете, виноваты ли диск, память, сервисы, контейнеры или ошибки.

Вопрос: «Здоров ли этот сервер?»

Сырой SSH

$ uptime
 10:42:17 up 18 days,  3:21,  2 users,  load average: 0.42, 0.31, 0.28
$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sda1      ext4    40G   35G  5.0G  87% /
overlay        overlay  40G   35G  5.0G  87% /var/lib/docker/overlay2/...
$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       4.9Gi       612Mi       121Mi       2.2Gi       2.5Gi
$ systemctl --failed
  UNIT              LOAD   ACTIVE SUB    DESCRIPTION
● api-worker.service loaded failed failed API background worker
$ docker ps -a
CONTAINER ID   IMAGE          STATUS                     PORTS
8e14d0b41c2a   api:latest     Up 3 minutes               0.0.0.0:8080->8080/tcp
65b894af2430   worker:latest  Exited (1) 2 minutes ago
$ ss -tulpn
Netid  State   Local Address:Port   Process
tcp    LISTEN  0.0.0.0:22          users:(("sshd",pid=842,fd=3))
tcp    LISTEN  0.0.0.0:8080        users:(("docker-proxy",pid=1942,fd=4))
$ journalctl -p err --since -1h | tail -50
Aug 20 10:39:14 prod api-worker[22104]: database connection timed out
Aug 20 10:39:14 prod systemd[1]: api-worker.service: Failed with result 'exit-code'.

Это всё ещё сокращённый результат. Полная проверка требует дополнительных команд для CPU, состояния сервисов, количества контейнеров и недавних ошибок, каждая со своим форматом вывода. Хуже того, машина без ss может выглядеть так, будто у неё ноль слушающих портов, если проверка портов так и не выполнилась.

Структурированный результат MCP

ssh_snapshot({ "profile": "production" })

{
  "disk_pct": 87,
  "mem_pct": 64,
  "cpu_pct": 12,
  "load": "0.42 0.31 0.28",
  "containers": 7,
  "ports": 14,
  "services_running": 3,
  "recent_errors": 21,
  "unavailable": []
}

Что получает агент

Полный результат ssh_audit_baseline может быть длиннее, чем несколько выводов сырых команд, — около 1077 токенов против 765 в наших лабораторных измерениях. Экономия возникает за счёт полного рабочего процесса, а не за счёт сокращения одного ответа.

В реальном сеансе устранения неполадок специализированные инструменты сократили 49 отдельных вызовов команд до 4 вызовов MCP. Каждый дополнительный вызов запускает новый виток модели с накопленным диалогом. Кэширование промптов может снизить стоимость повторяющегося ввода, но новые команды и их вывод по-прежнему занимают контекст. Меньше обращений означает меньше токенов за сеанс, меньше повторного анализа и более быстрый путь к ответу.

Нужна полная картина, а не только пульс? ssh_audit_baseline собирает в пакет систему, диск, память, порты, sshd, упавшие юниты, Docker, межсетевой экран и обновления. Результаты приходят как CRITICAL / WARNING / OK; неизмеренные разделы называются явно, а не молча читаются как ноль.

Поиск по логам Linux-сервера

Ситуация: API истекает по таймауту, но то же сообщение может быть в nginx, syslog, journald или в логе приложения, который вы не можете прочитать под обычным пользователем.

Вопрос: «Откуда взялась эта ошибка?»

Сырой SSH

$ grep -i "timeout" /var/log/nginx/error.log
2026/08/20 10:38:54 [error] upstream timed out while reading response header
$ grep -i "timeout" /var/log/syslog
Aug 20 10:39:14 prod api-worker[22104]: database connection timed out
$ grep -i "timeout" /var/log/app/*.log 2>/dev/null
$ journalctl -u api --since "1 hour ago" | grep -i timeout
Aug 20 10:39:14 prod api[22104]: database connection timed out after 30000ms

Третья команда выглядит чисто, но 2>/dev/null также скрыл ошибку прав доступа. «Ничего не найдено» и «ничего не прочитано» теперь выглядят одинаково. Активный лог может также вернуть тысячи строк и вытеснить остальную часть инцидента из контекста агента.

Структурированный результат MCP

ssh_log_search({ "profile": "production",
                 "path": ["/var/log/nginx/error.log", "/var/log/syslog", "/var/log/app/*.log"],
                 "query": "timeout", "context": 2, "since": "1h" })

{
  "matches": 34,
  "lines": [
    { "file": "/var/log/nginx/error.log", "line": 4821,
      "text": "upstream timed out while reading response header", "context": false },
    { "file": "/var/log/nginx/error.log", "line": 4822,
      "text": "client closed connection", "context": true }
  ],
  "files_searched": 6,
  "files_unreadable": ["/var/log/app/private"],
  "files_skipped": 12,
  "files_undated": [],
  "limited": false,
  "truncated": false
}

Что получает агент

since использует часы сервера, namesOnly: true возвращает только совпадающие пути, а ssh_log_tail читает последние N строк из нескольких логов за один вызов.

Безопасное удалённое редактирование конфигурации

Ситуация: Вам нужно заменить конфигурацию nginx на работающем сервере. Обрыв соединения, неправильный режим или непроверенная копия могут оставить сервис с повреждённым файлом.

Вопрос: «Могу ли я заменить этот конфиг, не оставив частичный файл?»

Сырой SSH

$ sudo sh -c 'cat > /etc/nginx/conf.d/api.conf' <<'EOF'
server {
    listen 80;
    location / { proxy_pass http://127.0.0.1:8080; }
}
EOF
$ echo $?
0

Код возврата ноль говорит, что оболочка завершилась. Он не доказывает, какие байты дошли, а > усекает старый файл до того, как пришёл первый байт нового. Если соединение оборвётся во время записи, сервис останется с частичной конфигурацией.

Структурированный результат MCP

ssh_file_write({ "profile": "production",
                 "files": [{ "path": "/etc/nginx/conf.d/api.conf",
                             "content": "server {\n    listen 80;\n    location / { proxy_pass http://127.0.0.1:8080; }\n}\n",
                             "mode": "644", "sudo": true, "verify": true }] })

{
  "files": [{ "path": "/etc/nginx/conf.d/api.conf", "written": true,
              "verified": "verified", "reason": null, "bytes": 79 }]
}

Что получает агент

У verified три честных исхода: verified, unavailable, когда на сервере нет инструмента для хеширования, и skipped, когда проверка не запрашивалась. Для чтения ssh_file_read принимает список путей; ssh_file_list обрабатывает glob-шаблоны, рекурсию, размеры и режимы.

Выполнять пакетные SSH-команды с sudo

Ситуация: Деплой готов, но синтаксис nginx, состояние службы и свежие ошибки нужно проверить до переключения трафика. Одна проваленная проверка не должна раствориться внутри объединённого вывода.

Вопрос: «Прошли ли все проверки перед деплоем?»

Raw SSH

$ ssh admin@server.example.com 'sudo nginx -t'
nginx: configuration file /etc/nginx/nginx.conf test is successful
$ ssh admin@server.example.com 'sudo systemctl is-active nginx'
active
$ ssh admin@server.example.com 'sudo tail -5 /var/log/nginx/error.log'
2026/08/20 10:38:54 [error] upstream timed out while reading response header

Три соединения возвращают три несвязанных вывода. Если команды объединить через ;, шелл сообщит только последний код возврата; если объединить через &&, более поздние проверки исчезнут после первого сбоя.

Структурированный результат MCP

ssh_exec({ "profile": "production",
           "command": ["nginx -t", "systemctl is-active nginx",
                       "tail -5 /var/log/nginx/error.log"],
           "sudo": true })

{
  "commands": [
    { "command": "nginx -t", "exit_code": 0, "truncated": false, "clipped_bytes": 0,
      "stdout": "", "stderr": "nginx: configuration file /etc/nginx/nginx.conf test is successful\n" },
    { "command": "systemctl is-active nginx", "exit_code": 0, "truncated": false,
      "clipped_bytes": 0, "stdout": "active\n", "stderr": "" },
    { "command": "tail -5 /var/log/nginx/error.log", "exit_code": 0, "truncated": false,
      "clipped_bytes": 0, "stdout": "2026/08/21 09:14:02 [error] upstream timed out\n", "stderr": "" }
  ],
  "job_id": null
}

Что получает агент

Защита от разрушительных команд проверяет весь список до запуска первой команды. Если одна запись отклонена, все остальные помечаются как не запущенные, и на сервер ничего не отправляется.

Каждая команда несёт собственные stdout и stderr. Команда, которая выполнилась и ничего не вывела, имеет пустую строку; команда, которая не выполнялась, вообще не имеет такого поля, так что их невозможно перепутать. Вывод более 128 КБ на команду сохраняет оба конца — начало для таблиц, хвост для логов — со швом посередине, указывающим объём, а clipped_bytes сообщает, сколько было обрезано. Обрезка происходит по границам байтов и отступает к краю символа, поэтому обрезанный ответ никогда не несёт знака замены.

sudo достигает сервера без терминала: если в профиле есть пароль, он передаётся sudo через стандартный ввод. Профиль, аутентифицирующийся по ключу, не имеет пароля для передачи, поэтому sudo там работает только там, где уже настроен без пароля — а команде, читающей собственный стандартный ввод, пароль не передаётся никогда, иначе он смешался бы с данными.

Запускать долгоживущие SSH-задания

Ситуация: Резервное копирование или миграция продлится дольше, чем сессия агента. Соединение может закрыться, но вам всё равно понадобятся его состояние, вывод и код возврата позже.

Вопрос: «Переживёт ли это задание разговор?»

Raw SSH

$ ssh admin@server.example.com 'pg_dump app | gzip > /srv/backups/app.sql.gz'
client_loop: send disconnect: Broken pipe

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

Структурированный результат MCP

ssh_exec({ "profile": "production",
           "command": "pg_dump app | gzip > /srv/backups/app.sql.gz",
           "detach": true })

{
  "commands": [{
    "command": "pg_dump app | gzip > /srv/backups/app.sql.gz",
    "exit_code": null,
    "truncated": false,
    "timed_out": false,
    "blocked": false,
    "blocked_reason": null,
    "not_run": false,
    "warning": null
  }],
  "job_id": "mst0f2q1-9ab3c4d5"
}

Что получает агент

Состояние задания хранится на удалённом диске, а не в памяти этого сервера. ssh_job_status различает running, finished и lost; ssh_job_output продолжает с последнего смещения в байтах; а ssh_job_kill сигналит всей группе процессов, а не только её шеллу.

Передавать файлы на устаревшие роутеры и NAS-устройства

Ситуация: Современный клиент OpenSSH пробует SFTP, но роутер или NAS понимает только классический протокол scp. Файл всё равно должен дойти целым и безопасно заменить целевой.

Вопрос: «Сможет ли это старое устройство принять проверенный файл?»

Raw SSH

$ scp app.conf operator@router:/etc/app.conf
subsystem request failed on channel 0
scp: Connection closed

Обычный следующий шаг — вспомнить флаг для устаревших систем, повторить копирование и затем выполнить отдельную команду хеширования — если на устройстве вообще есть инструмент хеширования.

Структурированный результат MCP

ssh_upload({ "profile": "router", "local_path": "./app.conf",
             "remote_path": "/etc/app.conf", "sudo": true,
             "mode": "644", "owner": "root:root", "verify": true })

{
  "files": [{
    "path": "/etc/app.conf",
    "written": true,
    "verified": "verified",
    "reason": null,
    "bytes": 1284
  }]
}

Что получает агент

Если на устройстве нет ни sha256sum, ни openssl, результат сообщает unavailable и называет причину вместо ложного совпадения. Целые каталоги используют recursive: true и проверяют свои хеши одним пакетом.

Защита от разрушительных команд для ИИ-агентов

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

Остановить разрушительную цепочку до её запуска

Безопасная последовательность «резервная копия и замена»:

cp -r /srv/app /srv/app.bak && mv /srv/app /srv/app-old && rm -rf /srv/app

Те же операции в неправильном порядке:

rm -rf /srv/app && cp -r /srv/app /srv/app.bak && mv /srv/app /srv/app-old
# REFUSED before the first command runs

Шелл удалил бы каталог и только потом обнаружил, что источник резервной копии исчез. Защита видит, что более поздние шаги читают цель, уже уничтоженную более ранним шагом, поэтому весь вызов остаётся на вашей машине. Та же проверка ловит dropdb app && pg_dump app > backup.sql.

Отказывать при необратимой потере, предупреждать о восстановимых изменениях

docker compose down -v отклоняется, потому что -v удаляет именованные Docker-тома, включая том базы данных. Без -v остановка служб не считается тем же необратимым действием.

Рекурсивное удаление корня файловой системы, домашнего каталога или системных деревьев, таких как /etc, /var и /usr, также отклоняется, в том числе когда туда ведёт символическая ссылка. Нераспознанная цель, такая как rm -rf "$DIR"/*, тоже отклоняется: «не удалось проверить» не считается «безопасно».

Подтвердить намеренную разрушительную команду

Ничто не запрещено навсегда. Добавьте # CONFIRMED-DESTRUCTIVE к проверенной команде — и она будет пропущена. Когда защита отклоняет одну запись в пакете, весь пакет останавливается до выполнения, так что сервер никогда не остаётся после наполовину выполненной операции.

Защита работает в пределах одного вызова. Она не может связать удаление в одном вызове с чтением в следующем или рассуждать об инструментах, которых не знает. Это ремень безопасности, а не движок политик: восстановимые операции остаются вашим решением. Ограничения путей и правила кавычек описаны в docs/security.md.

Инструменты SSH MCP для операций на сервере

18 инструментов. Полные параметры и примеры — в docs/tools.md.

Аннотации безопасности инструментов MCP

Стандартные аннотации MCP сообщают клиентам, какие инструменты доступны только для чтения, разрушительны, идемпотентны или открыты миру. См. полную таблицу.

Выполнять SSH-команды и управлять удалёнными файлами

Отслеживать долгоживущие SSH-задания

Искать в логах и проверять здоровье сервера

Загружать и скачивать файлы по SSH

Бинарно-безопасные передачи с проверкой целостности. Подробности в docs/transfer.md.

Для бинарных файлов и больших файлов используйте ssh_upload / ssh_download — блоки base64 и heredoc не являются бинарно-безопасными или атомарными.

Аудит Linux-серверов по SSH

Только чтение, одним пакетом за один обход. Подробности в docs/audit.md.

Windows SSH compatibility mode

Windows использует режим совместимости автоматически. Когда мультиплексирование соединений недоступно, сервер переключается на одно соединение на команду. Те же инструменты остаются доступными через SSH на основе ключей — не требуется отдельная настройка или реализация для Windows.

Защита от деструктивных команд описана в разделе Защита от деструктивных команд для ИИ-агентов.

Set up the SSH MCP server

Сначала запустите пакет из раздела Установка за 30 секунд, затем создайте файл профиля.

Create SSH connection profiles

Разместите его где угодно — обычно рядом с конфигом самого агента. В примерах ниже используется ~/.claude/ssh-profiles.json; для других агентов замените каталог (~/.codex/, ~/.qwen/, ~/.config/opencode/):

{
  "profiles": {
    "production": {
      "host": "server.example.com",
      "username": "admin",
      "port": 22,
      "privateKeyPath": "~/.ssh/your_private_key"
    }
  }
}

Выбор профиля SSH в явном виде

У сервера нет профиля по умолчанию: каждый профиль — это отдельная машина, и команда, отправленная не на ту машину, — это не то, что сообщение об ошибке сможет исправить задним числом. Если запросить без имени, в ответе будет список имён на выбор:

ssh_exec({ command: "uptime" })
→ No profile specified. Name one explicitly: production

Профиль, который сервер не может использовать для SSH — без host, без username или с mode: "local" — пропускается без возражений, а нераспознанные поля остаются нетронутыми, поэтому файл можно использовать совместно с другими инструментами. Профиль с битым полем — другой случай: он называется вместе с полем и значением, а его исправные соседи продолжают работать.

Каждый профиль может содержать блок pathSecurity, который разрешает или запрещает пути, к которым файловые инструменты могут обращаться — см. docs/security.md.

Keep SSH passwords and passphrases out of profiles

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

{
  "secretsFile": "~/.config/ssh-mcp/secrets.json",
  "profiles": {
    "production": {
      "host": "server.example.com",
      "username": "admin"
    }
  }
}

Файл секретов привязан к имени профиля — см. secrets.json.example:

{
  "production": { "password": "..." }
}

Файл секретов должен быть доступен для чтения только вам (chmod 600). Относительные пути разрешаются относительно файла профилей; секреты не попадают в argv и маскируются в журналах. См. безопасность учётных данных.

Configure Claude Code, Codex and other MCP clients

Выберите используемый клиент и укажите ему тот же файл профилей.

Claude Code

Одна команда; -s user делает сервер доступным в каждом проекте:

claude mcp add ssh -s user \
  -e SSH_PROFILES_FILE="$HOME/.claude/ssh-profiles.json" \
  -- npx -y @hypnosis/ssh-mcp-server

Codex CLI

codex mcp add ssh \
  --env SSH_PROFILES_FILE="$HOME/.codex/ssh-profiles.json" \
  -- npx -y @hypnosis/ssh-mcp-server

opencode

Поместите его в ~/.config/opencode/opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "ssh": {
      "type": "local",
      "command": ["npx", "-y", "@hypnosis/ssh-mcp-server"],
      "enabled": true,
      "environment": {
        "SSH_PROFILES_FILE": "~/.config/opencode/ssh-profiles.json"
      }
    }
  }
}

Qwen Code

Одна команда, как и у остальных:

qwen mcp add ssh \
  -e SSH_PROFILES_FILE="$HOME/.qwen/ssh-profiles.json" \
  npx -y @hypnosis/ssh-mcp-server

Другие MCP-клиенты

Gemini CLI, Hermes, Cline, плагин редактора или ваш собственный агент работают так же. Всё, что им нужно, — это команда для запуска и одна переменная окружения.

Restart your MCP client

Перезапустите клиент, затем выполните ssh_monitor({ action: "list" }), чтобы убедиться, что профиль загружен.

SSH MCP server configuration

Общее соединение намеренно переживает этот процесс: закрытие его при выходе оборвало бы канал, который использует другое окно на той же машине.

SSH MCP server limitations

• Отмена: закрытие SSH может оставить удалённую команду выполняющейся. Используйте отсоединённые задания, когда управление важно.

• Атомарные записи: BSD и macOS не могут заранее проверить переименования между файловыми системами.

SSH MCP server roadmap

• Полный прогон тестов на macOS SSH-хостах

• Сквозной прогон совместимости на Windows

• Многохостовые аудиты — сравнение состояния нескольких SSH-профилей одним вызовом

• Импорт профилей из существующего ~/.ssh/config

• Возобновляемые передачи для больших файлов и нестабильных соединений

• Хронология удалённых операций — команды, передачи и решения защиты в едином журнале аудита

• Готовые руководства по устранению неполадок SSH

• Ответы, которые доходят до модели — ГОТОВО: вывод команд, совпавшие строки журнала, имена машин и разделы снимков передаются в полях, а не только в тексте

• Более компактные схемы MCP-инструментов — ГОТОВО: список инструментов стал на 10% легче, а отсоединённое задание теперь показывает последние строки, которые оно записало, вместо слепого опроса

Develop and test the SSH MCP server

npm install
npm run build           # tsc
npx tsc --noEmit        # types, plus dead declarations
npm run test:unit       # unit tests
npm run lab:up          # start the two test containers
npm run test:live       # live suite against those containers

Живой набор тестов запускается на реальных контейнерах — один BusyBox, один coreutils — потому что эти два тихо расходятся во мнениях, а мок соглашается с тем, кто его написал. Структуру см. в docs/architecture.md.

Like SSH MCP Server? ⭐

Если вам нравится инструмент, поставьте ему звезду на GitHub — это помогает большему числу людей узнать о проекте.

Contribute to the SSH MCP server

Мы приветствуем issues и pull request'ы на github.com/hypnosis/ssh-mcp-server.

License

MIT — см. LICENSE.