प्रॉक्सी के माध्यम से SSH पहुँच
LLM एजेंट कच्ची SSH कुंजियों के बजाय SSH-प्रॉक्सी API से दूरस्थ मशीनों पर सुरक्षित रूप से कमांड कैसे चलाता है।
प्रॉक्सी के माध्यम से SSH पहुँच
एजेंटों को दूरस्थ मशीनों पर कमांड चलाने की आवश्यकता होती है — कंटेनर डिप्लॉय करना, लॉग पढ़ना, कॉन्फ़िग ठीक करना। LLM को कच्ची SSH निजी कुंजियाँ देना बुरा विचार है: कुंजियाँ संदर्भ विंडो, लॉग और ट्रांसक्रिप्ट में चली जाती हैं। SSH-प्रॉक्सी इसे हल करता है: क्रेडेंशियल उसी के पास रहते हैं, एजेंट केवल HTTP बोलता है।
मॉडल
LLM ──HTTPS──► SSH-प्रॉक्सी ──SSH──► लक्ष्य मशीनें
(कुंजियाँ रखता है,
ऑडिट लॉग,
रेट सीमाएँ)प्रॉक्सी सरल REST सतह के साथ स्थायी सत्रें उपलब्ध कराता है:
| एंडपॉइंट | उद्देश्य |
|---|---|
POST /connect?target=vps1 |
सत्र खोलें → session_id |
POST /<sid>/exec {command, timeout} |
कमांड चलाएँ (async) → exec_id |
GET /<sid>/exec/<exec_id> |
आउटपुट पोल करें |
| SFTP एंडपॉइंट | फ़ाइल अप/डाउनलोड, ls, mkdir, rm |
प्रमाणीकरण Bearer टोकन है — आपके उपयोग की हर अन्य API जैसा ही पैटर्न।
निष्पादन पैटर्न
# 1. एक बार कनेक्ट करें, पूरे कार्य के लिए सत्र पुनः उपयोग करें
SID=$(curl -s -H "Authorization: Bearer $KEY" \
"https://ssh-proxy.example/connect?target=vps1" | jq -r .session_id)
# 2. कमांड चलाएँ
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. परिणाम पोल करें
curl -s -H "Authorization: Bearer $KEY" "https://ssh-proxy.example/$SID/exec/$EID"आचरण के नियम
- सत्रों का पुनः उपयोग करें। प्रत्येक कमांड पर कनेक्ट होना संसाधन बर्बाद करता है और रेट सीमाएँ छूता है।
session_idसहेजें (जैसे/tmp/vps1_sid) और पुनः उपयोग से पहले हार्टबीट दें। - लक्ष्यों को नाम दें, खोजें नहीं। लक्ष्य पूर्व-पंजीकृत हैं (
vps1,pi, …)। प्रॉक्सी एकमात्र सत्य-स्रोत है — एजेंट कोड में IP पते कभी हार्डकोड न करें। - फ़ाइलों के लिए शेल cat/heredoc की बजाय SFTP को प्राथमिकता दें।
execके माध्यम से बाइनरी डेटा एस्केप करना पेलोड को दूषित करता है। समर्पित अप/डाउनलोड एंडपॉइंट का उपयोग करें। - अपने कमांड कोट करें। JSON बॉडी दो बार पार्स होती है (HTTP + शेल)। दूरस्थ कमांड को सिंगल कोट्स में लपेटें और एक-पंक्ति रखें।
- ऑडिटिंग मानें। हर exec प्रॉक्सी के ऑडिट लॉग में जाता है — ऐसे आचरण करें जैसे इंसान सब पढ़ता है (वह पढ़ सकता है)।
exec का उपयोग कब न करें
- ऐसी संरचित स्थिति पढ़ना जिसकी API है (Docker, डेटाबेस, Synapse की Mind API) — CLI आउटपुट पार्सिंग की बजाय हमेशा API को प्राथमिकता दें।
- लंबे समय चलने वाली संवादात्मक प्रक्रियाएँ।
execटाइमआउट सहित fire-and-forget है; इसके बजाय लक्ष्य परnohup+ स्थिति-फ़ाइल का उपयोग करें। - स्पष्ट निर्देश के बिना कोई भी विनाशकारी कार्य। प्रॉक्सी आपको शक्ति देता है — इंसान आपको अनुमति देता है।
त्रुटि पुनर्प्राप्ति
| लक्षण | समाधान |
|---|---|
| connect पर 401 | टोकन समाप्त — memory/settings से फिर पढ़ें, ट्रांसक्रिप्ट से कभी नहीं |
| सत्र 404 | सत्र समाप्त (24h सीमा) — फिर कनेक्ट करें |
| exec टाइमआउट | timeout बढ़ाएँ या कमांड विभाजित करें; लक्ष्य का भार जाँचें |
| दूषित फ़ाइल सामग्री | आपने SFTP के बजाय exec उपयोग किया — SFTP एंडपॉइंट पर जाएँ |