Dostęp SSH przez proxy
Jak agent LLM bezpiecznie wykonuje polecenia na zdalnych maszynach przez API proxy SSH zamiast surowych kluczy SSH.
Dostęp SSH przez proxy
Agenty muszą wykonywać polecenia na zdalnych maszynach — wdrażać kontener, czytać log, naprawiać konfigurację. Oddawanie surowych kluczy prywatnych SSH LLM to zły pomysł: klucze trafiają do okien kontekstu, logów i transkrypcji. Proxy SSH rozwiązuje to: to on posiada dane uwierzytelniające, agent mówi tylko HTTP.
Model
LLM ──HTTPS──► Proxy SSH ──SSH──► maszyny docelowe
(posiada klucze,
dziennik audytu,
limity zapytań)Proxy udostępnia trwałe sesje przez prostą powierzchnię REST:
| Endpoint | Cel |
|---|---|
POST /connect?target=vps1 |
otwarcie sesji → session_id |
POST /<sid>/exec {command, timeout} |
wykonanie polecenia (async) → exec_id |
GET /<sid>/exec/<exec_id> |
odpytanie o wyjście |
| Endpointy SFTP | wysyłanie/pobieranie plików, ls, mkdir, rm |
Uwierzytelnianie to token Bearer — ten sam wzorzec, co w każdej innej API, którą używasz.
Wzorzec wykonania
# 1. połącz raz, używaj sesji przez całe zadanie
SID=$(curl -s -H "Authorization: Bearer $KEY" \
"https://ssh-proxy.example/connect?target=vps1" | jq -r .session_id)
# 2. wykonaj polecenie
EID=$(curl -s -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
-X POST "https://ssh-proxy.example/$SID/exec" \
-d '{"command": "docker ps --format \"{{.Names}}\"", "timeout": 120}' | jq -r .exec_id)
# 3. odpytaj o wynik
curl -s -H "Authorization: Bearer $KEY" "https://ssh-proxy.example/$SID/exec/$EID"Reguły postępowania
- Używaj sesji ponownie. Łączenie na każde polecenie marnuje zasoby i uruchamia limity. Zapisz
session_id(np./tmp/vps1_sid) i daj mu heartbeat przed ponownym użyciem. - Nazywaj cele, nie odkrywaj ich. Cele są predefiniowane (
vps1,pi, …). Proxy jest jedynym źródłem prawdy — nigdy nie zaszywaj adresów IP w kodzie agenta. - Preferuj SFTP nad cat/heredoc shella dla plików. Escapowanie danych binarnych przez
execpsuje ładunki. Używaj dedykowanych endpointów wysyłania/pobierania. - Cytuj swoje polecenia. Treść JSON jest parsowana dwukrotnie (HTTP + shell). Owiń zdalne polecenia w pojedyncze cudzysłowy i trzymaj je w jednej linii.
- Zakładaj audyt. Każdy exec trafia do dziennika audytu proxy — zachowuj się tak, jakby człowiek czytał wszystko (może).
Kiedy NIE używać exec
- Czytanie ustrukturyzowanego stanu, który ma API (Docker, bazy danych, Mind API Synapse) — zawsze preferuj API nad parsowaniem wyjścia CLI.
- Długotrwałe procesy interaktywne.
execto fire-and-forget z timeoutem; użyjnohup+ pliku statusu na celu. - Cokolwiek destrukcyjnego bez wyraźnego polecenia. Proxy daje ci moc — człowiek daje ci pozwolenie.
Odzyskiwanie po błędach
| Objaw | Rozwiązanie |
|---|---|
| 401 przy connect | token wygasł — odczytaj go ponownie z memory/settings, nigdy z transkrypcji |
| sesja 404 | sesja wygasła (limit 24h) — połącz ponownie |
| timeout exec | zwiększ timeout albo podziel polecenie; sprawdź obciążenie celu |
| zepsuta zawartość pliku | użyłeś exec zamiast SFTP — przejdź na endpointy SFTP |