# SSH-доступ через прокси
SUMMARY: Как LLM-агент безопасно выполняет команды на удалённых машинах через HTTP-API SSH-прокси вместо сырых SSH-ключей.

KEY CONTEXT:
НИКОГДА не держите сырые приватные SSH-ключи как LLM. Используйте HTTP-API SSH-прокси:
1) POST /connect?target=<name> → session_id (постоянная, живёт часами).
2) POST /<session_id>/exec {command, timeout} → exec_id.
3) GET /<session_id>/exec/<exec_id> → вывод по готовности.
4) Для загрузки/скачивания файлов используйте SFTP-эндпоинты вместо cat/heredoc.
Цели — предзарегистрированные имена (напр. "vps1"), не IP — прокси — единственное
место, где живут учётные данные.

SSH-доступ через прокси
Агентам нужно выполнять команды на удалённых машинах — развернуть контейнер, прочитать лог, поправить конфиг. Давать сырые приватные SSH-ключи LLM — плохая идея: ключи попадают в окна контекста, логи и транскрипты. SSH-прокси решает это: учётные данные хранит он, агент говорит только по HTTP.
Модель
[CODE BLOCK]
Прокси отдаёт постоянные сессии через простой REST-поверхность:
| Эндпоинт | Назначение |
|---|---|
|  | открыть сессию →  |
|   | выполнить команду (async) →  |
|  | опросить вывод |
| SFTP-эндпоинты | загрузка/скачивание файлов, , ,  |
Аутентификация — Bearer-токен, тот же паттерн, что и во всех остальных API, которые вы используете.
Паттерн выполнения
[CODE BLOCK]
Правила поведения
1. Переиспользуйте сессии. Подключение на каждую команду тратит ресурсы и ловит лимиты частоты. Сохраните  (напр. ) и проверяйте его heartbeat перед повторным использованием.
2. Называйте цели, а не открывайте их. Цели предзарегистрированы (, , …). Прокси — единственный источник истины; никогда не зашивайте IP-адреса в код агента.
3. Предпочитайте SFTP вместо cat/heredoc для файлов. Экранирование бинарных данных через  портит полезную нагрузку. Используйте выделенные эндпоинты загрузки/скачивания.
4. Кавычьте свои команды. Тело JSON парсится дважды (HTTP + shell). Оборачивайте удалённые команды в одинарные кавычки и держите их в одну строку.
5. Считайте, что аудит ведётся. Каждый exec попадает в журнал аудита прокси — ведите себя так, будто человек читает всё (он может).
Когда exec использовать НЕ стоит
- Чтение структурированного состояния, у которого есть API (Docker, базы данных, Mind API Synapse) — всегда предпочитайте API разбору вывода CLI.
- Долгие интерактивные процессы.  — это fire-and-forget с таймаутом; вместо этого используйте  + файл статуса на целевой машине.
- Любое деструктивное действие без явной инструкции. Прокси даёт вам власть — человек даёт вам разрешение.
Восстановление после ошибок
| Симптом | Решение |
|---|---|
| 401 при connect | токен истёк — перечитайте его из memory/settings, никогда из транскрипта |
| сессия 404 | сессия истекла (лимит 24 ч) — переподключитесь |
| таймаут exec | поднимите  или разделите команду; проверьте нагрузку целевой машины |
| испорченное содержимое файла | вы использовали  вместо SFTP — перейдите на SFTP-эндпоинты |