SSH MCP Server

SSH MCP Server — दूरस्थ सर्वर उपकरण AI एजेंटों के लिए

एक SSH MCP सर्वर — एक मल्टीटूल जो आपका और आपके AI एजेंट का समय और टोकन बचाता है डिबगिंग, विकास और सर्वर रखरखाव में। कमांड चलाएँ, फ़ाइलें स्थानांतरित करें, लॉग पढ़ें और SSH के माध्यम से मशीनों का ऑडिट करें — एक क्लाउड VPS, एक बेयर-मेटल बॉक्स, या आपकी अलमारी में रखा BusyBox राउटर।

यह आपकी मशीन पर पहले से मौजूद OpenSSH क्लाइंट का उपयोग करता है: आपकी कुंजियाँ, आपका ~/.ssh/config, आपके जंप होस्ट, आपका एजेंट फ़ॉरवर्डिंग। कुछ भी बंडल नहीं, कुछ भी कंपाइल नहीं, कोई नेटिव बाइंडिंग नहीं।

Claude Code, Codex CLI, Cline, opencode, Gemini CLI, Qwen Code, Hermes और अन्य MCP क्लाइंट के साथ काम करता है।

इंस्टॉल करें · उपकरण · सेटअप · सुरक्षा · रोडमैप · दस्तावेज़ · चेंजलॉग

---

30 सेकंड में इंस्टॉल करें

कोई वैश्विक इंस्टॉलेशन आवश्यक नहीं। npx पहले उपयोग पर पैकेज डाउनलोड करता है:

npx -y @hypnosis/ssh-mcp-server

इसे अपने MCP क्लाइंट में जोड़ें — Claude Code, उदाहरण के लिए — हर प्रोजेक्ट के लिए:

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

या इसे हाथ से लिखें — वही सर्वर उस कॉन्फ़िग आकार में जो अधिकांश क्लाइंट साझा करते हैं:

{
  "mcpServers": {
    "ssh": {
      "command": "npx",
      "args": ["-y", "@hypnosis/ssh-mcp-server"],
      "env": {
        "SSH_PROFILES_FILE": "~/.claude/ssh-profiles.json"
      }
    }
  }
}

फिर कम से कम एक मशीन के साथ ~/.claude/ssh-profiles.json बनाएँ:

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

कनेक्ट करने के लिए यह पर्याप्त है।

Codex, opencode, Qwen Code और अन्य क्लाइंट इसमें शामिल हैं SSH MCP सर्वर सेट अप करें।

प्लगइन के रूप में इंस्टॉल करें

कुछ क्लाइंट — Claude Code, उदाहरण के लिए — पूरी चीज़ को प्लगइन के रूप में ले सकते हैं:

/plugin marketplace add hypnosis/ssh-mcp-server
/plugin install ssh-mcp-server@ssh-mcp-server

प्लगइन ~/.claude/ssh-profiles.json पढ़ता है जब तक SSH_PROFILES_FILE अन्यथा न कहे, इसलिए पहले वह फ़ाइल बनाएँ और सर्वर आपकी मशीनों के साथ पहले से लोड होकर आएगा।

आवश्यकताएँ

Node.js 18+ और PATH पर एक सिस्टम ssh क्लाइंट। Windows पर, कुंजी-आधारित प्रोफ़ाइल का उपयोग करें; पासवर्ड और पासफ़्रेज़ प्रोफ़ाइल वर्तमान में उपलब्ध नहीं हैं।

पिन किया हुआ संस्करण, ऑफ़लाइन कार्य, या प्रति लॉन्च एक कम रजिस्ट्री जाँच पसंद करते हैं: npm install -g @hypnosis/ssh-mcp-server, फिर npx के बजाय ssh-mcp-server को कमांड के रूप में उपयोग करें।

यह किसके लिए है

• DevOps और SRE जो तेज़ ऑडिट, घटना जाँच और नियमित सर्वर कार्य चाहते हैं।
• Vibe कोडर और इंडी बिल्डर जो AI सहायक के साथ शिप करते हैं और जो बनाते हैं उसे चलाते हैं अपने स्वयं के सर्वर पर।
• सिसएडमिन और प्लेटफ़ॉर्म इंजीनियर जो अप्रतिबंधित कच्चे शेल के बजाय संरचित उपकरण चाहते हैं।
• डेवलपर और छोटी टीमें जो समर्पित ऑपरेशन टीम के बिना अपना VPS चलाते हैं।
• होमलैब, NAS और राउटर मालिक जिनके उपयोगी हार्डवेयर ने अपने आधुनिक प्रोटोकॉल से अधिक समय तक काम किया है।

कच्चे शेल के बजाय SSH MCP सर्वर क्यों

कम टोकन, कम AI लागत

कच्चा शेल AI एजेंट को एक फायरहोज़ देता है: बार-बार कमांड, ASCII टेबल और लॉग डंप। यह उस शोर को सर्वर की तस्वीर में बदलने में टोकन जलाता है — आपका पैसा।

तेज़ सर्वर डिबगिंग

उद्देश्य-निर्मित उपकरण नियमित जाँचों को बैच करते हैं, शोरगुल वाले आउटपुट को सीमित करते हैं और महत्वपूर्ण हिस्सा लौटाते हैं। एजेंट टर्मिनल आउटपुट का अनुवाद करने में कम समय बिताता है और समाधान तक जल्दी पहुँचता है।

कम अनुमान, कम AI गलतियाँ

संरचित उत्तर बताते हैं कि क्या पाया गया, क्या मापा नहीं जा सका और क्या छोटा किया गया। यह एजेंट को भ्रम से अंतराल भरने के लिए कम जगह देता है — और आपको कम बुरे फिक्स, शांत डिप्लॉय और अधिक विश्वसनीय कोड देता है।

SSH संगतता: आधुनिक सर्वर, पुराने उपकरण और Windows

अपने मौजूदा OpenSSH सेटअप का उपयोग करें

कोई बंडल SSH कार्यान्वयन नहीं, कोई नेटिव बाइंडिंग नहीं, प्रति प्लेटफ़ॉर्म कोई रीबिल्ड नहीं। कमांड सिस्टम ssh क्लाइंट पर चलते हैं, इसलिए आपकी कुंजियाँ, आपका ~/.ssh/config, आपके जंप होस्ट और आपका एजेंट फ़ॉरवर्डिंग सब ठीक वैसे ही काम करते रहते हैं जैसे टर्मिनल में। जब समर्थित हो, प्रति गंतव्य एक साझा मल्टीप्लेक्स कनेक्शन का मतलब है कि आप एक बार प्रमाणित करते हैं, प्रति कमांड नहीं।

पुराने सर्वर, राउटर और NAS उपकरणों के लिए SSH समर्थन

आधुनिक scp वाले राउटर को फ़ाइल भेजें और आपको यह मिलता है:

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

कुछ भी टूटा नहीं है — एक वर्तमान scp नया प्रोटोकॉल बोलता है, और राउटर इसे नहीं जानता। टर्मिनल में अब आप एक फ़ोरम थ्रेड पढ़ने जाते हैं और एक अतिरिक्त फ़्लैग के साथ लौटते हैं। यहाँ आप कुछ नहीं करते: स्थानांतरण का प्रयास किया जाता है, अस्वीकृति पहचानी जाती है, पुराना प्रोटोकॉल उपयोग किया जाता है, और वह मशीन याद रखी जाती है ताकि अगली फ़ाइल सीधे वहाँ जाए।

पुराने SSH क्लाइंट और लापता उपकरणों के लिए फ़ॉलबैक

पुराने उपकरणों को मृत अंत नहीं, फ़ॉलबैक मिलता है। जब कोई आधुनिक सुविधा गायब होती है, सर्वर जहाँ संभव हो पुराना रास्ता लेता है:

आपकी मशीन	आपको क्या मिलता है
एक राउटर या NAS जो आधुनिक फ़ाइल स्थानांतरण के लिए बहुत छोटा है	फ़ाइल फिर भी पहुँचती है — पुराना प्रोटोकॉल स्वचालित रूप से उपयोग किया जाता है
दस साल पुराना सर्वर	वर्कफ़्लो फिर भी काम करता है; यह प्रति कमांड एक नया कनेक्शन खोलता है बजाय पुन: उपयोग करने के
एक छीन ली गई छवि जिसमें फ़ाइल हैश करने का कोई तरीका नहीं	अपलोड कहता है "सत्यापित नहीं कर सका" बजाय उस मैच का दावा करने के जिसे किसी ने जाँचा नहीं
एक बॉक्स जहाँ कोई उपकरण बस स्थापित नहीं है	उत्तर कहता है "मापा नहीं गया" — कभी शून्य नहीं जो "वहाँ कुछ नहीं है" पढ़ता है

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	संरचित MCP	आपका लाभ
कई कमांड और ASCII टेबल	एक परिणाम में नामित फ़ील्ड	एक कॉल, नामित फ़ील्ड और कम राउंड ट्रिप
एक लापता उपकरण खाली आउटपुट जैसा दिख सकता है	unavailable नाम देता है कि क्या मापा नहीं गया	कम अनुमान और कम बुरे फिक्स
आप डिस्क, सेवाओं और त्रुटियों के माध्यम से छाँटते हैं	समस्या संकेत पहले से सतह पर हैं	तेज़ डिबगिंग

एक पूर्ण ssh_audit_baseline परिणाम मुट्ठी भर कच्चे कमांड आउटपुट से लंबा हो सकता है — हमारे प्रयोगशाला माप में लगभग 1,077 टोकन बनाम 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
}

एजेंट को क्या मिलता है

कच्चा SSH	संरचित MCP	आपका लाभ
चार खोज और चार आउटपुट	फ़ाइलों और ग्लोब्स में एक खोज	कम टोकन और राउंड ट्रिप
अनुमति त्रुटियाँ गायब हो सकती हैं	files_unreadable हर छूटे पथ का नाम देता है	कोई झूठा "लॉग साफ हैं" निष्कर्ष नहीं
आउटपुट उपयोगी सीमा के बिना बढ़ सकता है	limited और truncated हर कटऑफ़ उजागर करते हैं	आंशिक परिणामों से सुरक्षित निर्णय

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 }]
}

एजेंट को क्या मिलता है

कच्चा SSH	संरचित MCP	आपका लाभ
प्रतिलिपि पूरी होने से पहले लक्ष्य छोटा किया जाता है	एक पूर्ण अस्थायी फ़ाइल इसे एक नाम बदलने के साथ बदलती है	कोई आधा-लिखा कॉन्फ़िग नहीं
केवल एग्ज़िट कोड	बाइट और सत्यापन परिणाम नामित हैं	आप जानते हैं कि वास्तव में क्या पहुँचा
अनुमतियाँ शेल टेक्स्ट के अंदर रहती हैं	sudo, mode और verify प्रति-फ़ाइल फ़ील्ड हैं	पूर्वानुमानित स्वामित्व और कम उद्धरण गलतियाँ

verified के तीन ईमानदार परिणाम हैं: verified, unavailable जब सर्वर के पास कोई हैश उपकरण नहीं है, और skipped जब सत्यापन का अनुरोध नहीं किया गया था। पढ़ने के लिए, ssh_file_read पथों की एक सूची स्वीकार करता है; ssh_file_list ग्लोब्स, पुनरावृत्ति, आकार और मोड संभालता है।

sudo के साथ बैच SSH कमांड चलाएँ

स्थिति: एक डिप्लॉय तैयार है, लेकिन nginx सिंटैक्स, सेवा स्थिति और हाल की त्रुटियाँ सभी ट्रैफ़िक स्थानांतरित होने से पहले जाँची जानी चाहिए। एक विफल जाँच संयुक्त डंप के अंदर गायब नहीं होनी चाहिए।

प्रश्न: "क्या हर प्रीफ़्लाइट जाँच पास हुई?"

कच्चा 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
}

एजेंट को क्या मिलता है

कच्चा SSH	संरचित MCP	आपका लाभ
तीन कॉल और असंबंधित आउटपुट	एक क्रमबद्ध कमांड सूची	कम राउंड ट्रिप
एक संयुक्त शेल मध्यवर्ती स्थिति छिपा सकता है	हर कमांड अपना स्वयं का exit_code रखता है	कोई छूटी विफल जाँच नहीं
sudo और उद्धरण कमांड टेक्स्ट में दोहराए जाते हैं	sudo पूरे बैच पर लागू होता है	कम उद्धरण गलतियाँ

विनाशकारी-कमांड गार्ड पहले कमांड चलने से पहले पूरी सूची जाँचता है। यदि एक प्रविष्टि अस्वीकार की जाती है, हर अन्य प्रविष्टि को नहीं चलाया गया के रूप में चिह्नित किया जाता है और सर्वर को कुछ भी नहीं भेजा जाता है। प्रत्येक कमांड अपने साथ stdout और stderr रखता है। एक कमांड जो चला और कुछ भी प्रिंट नहीं किया उसका मान एक खाली स्ट्रिंग होता है; एक कमांड जो कभी चला ही नहीं उसमें ऐसा कोई फ़ील्ड होता ही नहीं, इसलिए दोनों को भ्रमित नहीं किया जा सकता। प्रति कमांड 128 KB से अधिक का आउटपुट दोनों सिरों को रखता है — टेबल के लिए शुरुआत, लॉग के लिए अंत — बीच में एक सीमा होती है जो मात्रा का नाम बताती है, और clipped_bytes बताता है कि कितना काटा गया। कटाई बाइट सीमाओं पर होती है और एक कैरेक्टर के किनारे तक पीछे हटती है, इसलिए क्लिप किया गया उत्तर कभी भी प्रतिस्थापन चिह्न नहीं रखता।

sudo बिना टर्मिनल के सर्वर तक पहुँचता है: प्रोफ़ाइल का उत्तर sudo को मानक इनपुट पर दिया जाता है। वह कौन सा रहस्य है यह sudoPassword से आता है जब प्रोफ़ाइल एक का नाम लेती है और अन्यथा password से — एक प्रोफ़ाइल जो कुंजी द्वारा लॉगिन करती है उसका कोई लॉगिन पासवर्ड ही नहीं होता, और जहाँ एक मशीन दोनों को अलग रखती है वहाँ लॉगिन वाला गलत उत्तर होता है। जहाँ उत्तर देने के लिए कुछ नहीं होता, वहाँ उत्तर यह कहता है और बाहर निकलने के रास्ते बताता है, बजाय sudo के अपने -S और askpass सहायकों के बारे में सलाह छोड़ने के। एक कमांड जो अपना स्वयं का मानक इनपुट पढ़ता है उसे कभी पासवर्ड नहीं दिया जाता, अन्यथा वह डेटा में मिल जाता।

लंबे समय तक चलने वाले SSH कार्य चलाएँ

स्थिति: एक बैकअप या माइग्रेशन एजेंट सत्र से अधिक समय तक चलेगा। कनेक्शन बंद हो सकता है, लेकिन आपको बाद में उसकी स्थिति, आउटपुट और एग्ज़िट कोड की आवश्यकता होगी।

प्रश्न: "क्या यह कार्य बातचीत से बच जाएगा?"

रॉ 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	संरचित MCP	आपका लाभ
कार्य एक SSH सत्र से बंधा है	दूरस्थ कार्य का एक स्थायी आईडी है	सुरक्षित डिस्कनेक्ट और पुनरारंभ
पुनः कनेक्ट करने का अर्थ है प्रक्रियाओं और फ़ाइलों की खोज	स्थिति और एग्ज़िट कोड के नामित अवस्थाएँ हैं	यह अनुमान लगाने की आवश्यकता नहीं कि यह समाप्त हुआ
आउटपुट को फिर से पढ़ना पुराना पाठ दोहराता है	आउटपुट बाइट ऑफ़सेट से जारी रहता है	लंबे कार्यों पर कम टोकन उपयोग

कार्य की स्थिति दूरस्थ डिस्क पर रहती है, इस सर्वर की मेमोरी में नहीं। ssh_job_status running, finished और lost के बीच अंतर करता है; ssh_job_output अंतिम बाइट ऑफ़सेट से जारी रहता है; और ssh_job_kill केवल उसके शेल के बजाय पूरे प्रोसेस समूह को संकेत देता है।

लीगेसी राउटर और NAS उपकरणों में फ़ाइलें स्थानांतरित करें

स्थिति: एक वर्तमान OpenSSH क्लाइंट SFTP आज़माता है, लेकिन राउटर या NAS केवल क्लासिक scp प्रोटोकॉल समझता है। फ़ाइल को फिर भी बरकरार पहुँचना चाहिए और अपने लक्ष्य को सुरक्षित रूप से बदलना चाहिए।

प्रश्न: "क्या यह पुराना उपकरण अभी भी सत्यापित फ़ाइल प्राप्त कर सकता है?"

रॉ 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
  }]
}

एजेंट को क्या लाभ

रॉ SSH	संरचित MCP	आपका लाभ
आधुनिक SFTP मोड पहली त्रुटि पर रुक जाता है	क्लासिक scp फ़ॉलबैक स्वचालित और याद रखा जाता है	पुराना उपकरण अभी भी काम करता है
सफल कॉपी अखंडता साबित नहीं करती	SHA-256 सत्यापन का एक नामित परिणाम है	भ्रष्टाचार को सफलता नहीं समझा जाता
सीधा प्रतिस्थापन आंशिक लक्ष्य छोड़ सकता है	स्थानांतरण के बाद एक अस्थायी फ़ाइल को स्थान पर ले जाया जाता है	कार्यशील फ़ाइल व्यवधानों से बच जाती है

यदि उपकरण के पास न तो sha256sum है और न ही openssl, तो परिणाम unavailable कहता है और झूठे मिलान की रिपोर्ट करने के बजाय कारण बताता है। पूरी निर्देशिकाएँ recursive: true का उपयोग करती हैं और एक बैच में अपने हैश सत्यापित करती हैं।

AI एजेंटों के लिए विनाशकारी कमांड सुरक्षा

गार्ड स्थानीय रूप से चलता है, कमांड 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 को पकड़ती है।

अपरिवर्तनीय हानि से इनकार करें, पुनर्प्राप्त करने योग्य परिवर्तनों के बारे में चेतावनी दें

अस्वीकृत — कंटेनर स्वयं	केवल चेतावनी — उसकी सामग्री
DROP DATABASE, dropdb	DROP TABLE, TRUNCATE, DELETE FROM
docker volume rm, docker compose down -v	docker rm -f <name>
crontab -r	एक कार्य संपादित करना
mkfs, wipefs -a, lvremove, zfs destroy	chmod 777
reboot, shutdown, halt	git reset --hard

docker compose down -v अस्वीकृत है क्योंकि -v नामित Docker वॉल्यूम हटाता है, जिसमें एक डेटाबेस वॉल्यूम भी शामिल है। -v के बिना, सेवाओं को रोकना उसी अपरिवर्तनीय क्रिया के रूप में नहीं माना जाता।

फ़ाइलसिस्टम रूट, एक होम निर्देशिका या /etc, /var और /usr जैसे सिस्टम ट्री का पुनरावर्ती विलोपन भी अस्वीकृत है, जिसमें एक सिमलिंक वहाँ ले जाने पर भी शामिल है। rm -rf "$DIR"/* जैसा एक अनसुलझा लक्ष्य भी अस्वीकृत है: "जाँच नहीं कर सका" को "सुरक्षित" नहीं माना जाता।

आप जो रोकते हैं उसका नाम बताएं

एक कमांड जो अपने लक्ष्य को नाम देने के बजाय ढूंढता है, भेजा नहीं जाता। सर्वर इसे विस्तारित करता है और उत्तर देता है कि लक्ष्य के पीछे क्या है:

docker kill $(docker ps -q --filter ancestor=web)
# BLOCKED — would stop:
#   edge — web:latest, Up 34 days, 0.0.0.0:8443->8443/tcp

एक प्रक्रिया के लिए उत्तर उन संकेतों को जोड़ता है कि यह उपयोग में है: यह कितने समय से चल रही है, यह किन पोर्ट्स पर कनेक्शन स्वीकार करती है, यह कितने कनेक्शन ले जा रही है। नामित लक्ष्यों की कोई अतिरिक्त लागत नहीं होती और वे मौन में गुजर जाते हैं — docker kill web-1, kill 4871, systemctl stop app।

आगे बढ़ने के लिए, जो रोका जा रहा है उसका नाम बताएं। नामों की जाँच उस चीज़ के विरुद्ध की जाती है जिस तक कमांड वास्तव में पहुँचता है, इसलिए एक मास्क जो किसी और चीज़ पर बह गया है, पुष्टि करने के बजाय अस्वीकृत हो जाता है:

docker kill $(docker ps -q --filter ancestor=web) # CONFIRMED-KILL: edge

कमांड लाइनों पर एक पैटर्न अपने आप में एक मामला है। यह उसी कमांड से मेल खाता है जो इसे ले जाता है, इसलिए इसे चलाने वाला शेल लक्ष्य से पहले संकेतित होता है और उत्तर बीच में टूट जाता है। ऐसा प्रहार पुष्टि नहीं किया जाता बल्कि फिर से लिखा जाता है — संख्या द्वारा, या एक कैरेक्टर को एक वर्ग के रूप में लिखकर ताकि पैटर्न स्वयं से मेल खाना बंद कर दे:

pkill -f relay
# BLOCKED — two ways through:
#   kill 4871
#   pkill -f '[r]elay' # CONFIRMED-KILL: 4871

तीन परिणाम अलग रहते हैं: लक्ष्य मिले, विस्तार कुछ भी नहीं पहुँचा, और पूछने के लिए कुछ नहीं — मशीन पर कोई इंजन नहीं, एक क्लिप किया गया उत्तर, एक कनेक्शन जो विफल रहा। अंतिम दो भी अस्वीकृति हैं: न जानना आगे बढ़ने का कारण नहीं है।

एक जानबूझकर विनाशकारी कमांड की पुष्टि करें

कुछ भी स्थायी रूप से निषिद्ध नहीं है। एक समीक्षित कमांड में # CONFIRMED-DESTRUCTIVE जोड़ें और इसे अनुमति दी जाती है। जब गार्ड एक बैच में एक प्रविष्टि को अस्वीकार करता है, तो पूरा बैच निष्पादन से पहले रुक जाता है, इसलिए सर्वर कभी भी आधे-चले ऑपरेशन के बाद नहीं छोड़ा जाता।

गार्ड एक एकल कॉल के भीतर काम करता है। यह एक आह्वान में विलोपन को अगले में पढ़ने से नहीं जोड़ सकता, या उन उपकरणों के बारे में तर्क नहीं कर सकता जिन्हें यह पहचानता नहीं है। यह एक सीटबेल्ट है, नीति इंजन नहीं: पुनर्प्राप्त करने योग्य ऑपरेशन आपका निर्णय बने रहते हैं। पथ प्रतिबंध और उद्धरण नियम docs/security.md में प्रलेखित हैं।

उपकरण

सर्वर संचालन के लिए 18 SSH MCP उपकरण। पूर्ण पैरामीटर और उदाहरण docs/tools.md में रहते हैं।

उपकरण	यह क्या करता है
ssh_exec	एक कमांड या एक बैच चलाएँ, विनाशकारी-कमांड गार्ड और वैकल्पिक डिटैच के साथ
ssh_file_read	एक या कई फ़ाइलें पढ़ें, पाठ या बाइनरी
ssh_file_write	परमाणु नाम बदलने और वैकल्पिक SHA-256 सत्यापन के साथ फ़ाइलें लिखें
ssh_file_list	एक निर्देशिका सूचीबद्ध करें, वैकल्पिक ग्लोब और पुनरावृत्ति के साथ
ssh_upload	SSH पर एक फ़ाइल या निर्देशिका अपलोड करें, अखंडता जाँच के साथ बाइनरी-सुरक्षित; एक निर्देशिका लक्ष्य को बदल देती है या उसमें विलीन हो जाती है
ssh_download	SSH पर एक फ़ाइल या निर्देशिका डाउनलोड करें, अखंडता जाँच के साथ बाइनरी-सुरक्षित
ssh_job_status	एक पृष्ठभूमि कार्य की स्थिति: चल रहा है, समाप्त, या खो गया
ssh_job_output	बाइट ऑफ़सेट से संचित आउटपुट पढ़ें
ssh_job_list	कार्य सूचीबद्ध करें, अपने TTL से परे समाप्त कार्यों को साफ़ करते हुए
ssh_job_kill	एक कार्य के पूरे प्रोसेस समूह को संकेत दें
ssh_log_tail	एक या कई लॉग की अंतिम N पंक्तियाँ, ग्लोब समर्थित; नाम से एक कंटेनर
ssh_log_search	लॉग में पैटर्न खोज, या एक कंटेनर के लॉग के माध्यम से
ssh_snapshot	एक-शॉट स्वास्थ्य स्नैपशॉट: सेवाएँ, संसाधन, Docker, नेटवर्क, त्रुटियाँ
ssh_monitor	परिवहन नियंत्रण: आँकड़े, पुनः लोड, परीक्षण, सूची, बंद
ssh_audit_baseline	सिस्टम, डिस्क, मेमोरी, नेटवर्क, ssh, सेवाएँ, Docker, फ़ायरवॉल, अपडेट
ssh_tls_check	एक डोमेन के लिए प्रमाणपत्र समाप्ति, SAN, श्रृंखला और नवीनीकरण हुक
ssh_disk_breakdown	डिस्क कहाँ गई: du शीर्ष-N, Docker, journald, कैश
ssh_service_status	systemctl status प्लस एक इकाई के लिए एक journalctl टेल

MCP उपकरण सुरक्षा एनोटेशन

मानक MCP एनोटेशन क्लाइंट को बताते हैं कि कौन से उपकरण केवल-पढ़ने योग्य, विनाशकारी, इडेम्पोटेंट या ओपन-वर्ल्ड हैं। पूर्ण तालिका देखें।

SSH कमांड चलाएँ और दूरस्थ फ़ाइलें प्रबंधित करें

कमांड, फ़ाइल पढ़ना और लिखना, निर्देशिका सूची — एक मशीन पर सामान्य काम, प्रत्येक उत्तर पहले से पार्स किया गया।

लंबे समय तक चलने वाले SSH कार्यों की निगरानी करें

धीमा काम प्रतीक्षा करने के बजाय डिटैच और अनुसरण किया जाता है: हर नज़र बताती है कि यह कितनी दूर पहुँच गया।

लॉग खोजें और सर्वर स्वास्थ्य जाँचें

फ़ाइलों और कंटेनरों के लॉग, और मशीन की एक-शॉट तस्वीर, आउटपुट सीमित के साथ ताकि एक टेल संदर्भ विंडो न खा जाए।

SSH पर फ़ाइलें अपलोड और डाउनलोड करें

अखंडता जाँच के साथ बाइनरी-सुरक्षित स्थानांतरण। विवरण docs/transfer.md में।

बाइनरी और बड़ी फ़ाइलों के लिए ssh_upload / ssh_download का उपयोग करें — base64 चंक और heredocs बाइनरी-सुरक्षित या परमाणु नहीं हैं।

SSH पर Linux सर्वर का ऑडिट करें

केवल-पढ़ने योग्य और एक राउंड ट्रिप में बैच किया गया। विवरण docs/audit.md में।

Windows SSH संगतता मोड

Windows स्वचालित रूप से संगतता मोड का उपयोग करता है। जब कनेक्शन मल्टीप्लेक्सिंग अनुपलब्ध होती है, तो सर्वर प्रति कमांड एक कनेक्शन पर स्विच करता है। समान उपकरण कुंजी-आधारित SSH पर उपलब्ध रहते हैं — कोई अलग सेटअप या Windows-विशिष्ट कार्यान्वयन नहीं।

विनाशकारी-कमांड गार्ड AI एजेंटों के लिए विनाशकारी कमांड सुरक्षा में शामिल है।

SSH MCP सर्वर सेट करें

पहले 30 सेकंड में इंस्टॉल करें से पैकेज चलाएँ, फिर एक प्रोफ़ाइल फ़ाइल बनाएँ।

SSH कनेक्शन प्रोफ़ाइल बनाएँ

इसे जहाँ चाहें रखें — अपने एजेंट के अपने कॉन्फ़िग के पास सामान्य विकल्प है। नीचे के उदाहरण ~/.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 देखें।

एक प्रोफ़ाइल जो कुंजी द्वारा लॉगिन करती है लेकिन दूर की ओर sudo की आवश्यकता होती है वह एक sudoPassword लेती है — वह रहस्य जिसके साथ sudo का उत्तर दिया जाता है, जो कई मशीनों पर लॉगिन पासवर्ड नहीं है। इसे यहाँ के बजाय रहस्य फ़ाइल में रखें।

SSH पासवर्ड और पासफ़्रेज़ को प्रोफ़ाइल से बाहर रखें

कुंजियों को प्राथमिकता दें। यदि पासवर्ड या एन्क्रिप्टेड-कुंजी पासफ़्रेज़ अपरिहार्य है, तो उसे एक अलग सीक्रेट्स फ़ाइल में रखें, प्रोफ़ाइल में कभी नहीं:

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

सीक्रेट्स फ़ाइल प्रोफ़ाइल नाम से कुंजीबद्ध है — secrets.json.example देखें:

{
  "production": { "password": "..." },
  "buildbox": { "sudoPassword": "..." }
}

sudoPassword वह है जो उस मशीन पर sudo का उत्तर दिया जाता है। कुंजी से लॉगिन करने वाली प्रोफ़ाइल के पास देने के लिए कोई लॉगिन पासवर्ड नहीं होता, और जहाँ दोनों भिन्न होते हैं वहाँ लॉगिन वाला गलत उत्तर होता है; इसके बिना, password का उपयोग किया जाता है।

सीक्रेट्स फ़ाइल केवल आपके द्वारा पठनीय होनी चाहिए (chmod 600)। सापेक्ष पथ प्रोफ़ाइल फ़ाइल से हल होते हैं; सीक्रेट्स argv से बाहर रहते हैं और लॉग में मास्क किए जाते हैं। देखें क्रेडेंशियल सुरक्षा।

Claude Code, Codex और अन्य MCP क्लाइंट कॉन्फ़िगर करें

अपना उपयोग किया जाने वाला क्लाइंट चुनें और उसे उसी प्रोफ़ाइल फ़ाइल की ओर इंगित करें।

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, एक एडिटर प्लगइन या आपका अपना एजेंट उसी तरह काम करते हैं। उन्हें बस एक कमांड चलाने और एक पर्यावरण चर की आवश्यकता होती है।

अपना MCP क्लाइंट पुनः आरंभ करें

क्लाइंट को पुनः आरंभ करें, फिर प्रोफ़ाइल लोड होने की पुष्टि करने के लिए ssh_monitor({ action: "list" }) चलाएँ।

SSH MCP सर्वर कॉन्फ़िगरेशन

चर	यह क्या करता है	डिफ़ॉल्ट
SSH_PROFILES_FILE	प्रोफ़ाइल JSON का पथ — आवश्यक	—
SSH_MCP_LOG_LEVEL	debug, info, warn, error	info
LOG_LEVEL	फ़ॉलबैक, केवल तब उपयोग होता है जब SSH_MCP_LOG_LEVEL अनसेट हो	info
SSH_MCP_LOG_TIMESTAMP	लॉग पंक्तियों में टाइमस्टैम्प	true
SSH_MCP_CONTROL_PERSIST	अंतिम कमांड के बाद साझा कनेक्शन कितने सेकंड जीवित रहता है; 0 इसे तुरंत बंद कर देता है	600
SSH_MCP_CONTROL_DIR	नियंत्रण सॉकेट कहाँ रहते हैं	~/.ssh/ssh-mcp
SSH_MCP_PROFILES_CACHE_TTL	प्रोफ़ाइल कैश TTL, ms	60000
SSH_MCP_PROFILES_WATCH	प्रोफ़ाइल फ़ाइल बदलने पर उसे पुनः लोड करें	true

साझा कनेक्शन जानबूझकर इस प्रक्रिया से अधिक समय तक जीवित रहता है: बाहर निकलने पर इसे बंद करना उसी मशीन पर दूसरी विंडो द्वारा उपयोग किए जा रहे चैनल को काट देगा।

SSH MCP सर्वर सीमाएँ

हर सीमा आपको उससे बाहर निकलने का रास्ता बताती है। एक उपकरण जो कुछ नहीं कर सकता वह ऐसा कहता है और ssh_exec का नाम लेता है, जो मशीन पर सीधे कमांड चलाता है — एक असमर्थित लॉग ड्राइवर, एक उपयोगिता जो मशीन के पास नहीं है, एक इंजन जो यह सर्वर नहीं बोलता। आपको पहले से जानने की आवश्यकता नहीं है कि उपकरण कहाँ समाप्त होते हैं: अस्वीकृति इसे कहती है, उस क्षण जब यह मायने रखता है।

तीन अस्वीकृतियाँ जानबूझकर शेल के बारे में चुप रहती हैं, क्योंकि वहाँ यह गलत उत्तर है: एक पथ जो आपकी प्रोफ़ाइल मना करती है (अपने स्वयं के नियम के चारों ओर घूमना समाधान नहीं है), एक गलत-निर्मित कॉल (समाधान कॉल में है), और ssh_exec से ही एक अस्वीकृति।

• रद्दीकरण: एक रद्द किया गया कॉल अब सर्वर पर कमांड को भी रोक देता है, उसी कनेक्शन पर दूसरे कॉल के रूप में भेजा जाता है। जहाँ सर्वर के पास /proc नहीं है, वहाँ कमांड ps के माध्यम से पाया जाता है। FreeBSD सत्यापित नहीं है: वहाँ सही व्यवहार की गारंटी नहीं है। फ़ाइल स्थानांतरण और ssh_snapshot रद्दीकरण बिल्कुल स्वीकार नहीं करते।
• परमाणु लेखन: BSD और macOS क्रॉस-फ़ाइलसिस्टम नाम बदलने की पूर्व-जाँच नहीं कर सकते।

SSH MCP सर्वर रोडमैप

• macOS SSH होस्ट के विरुद्ध पूर्ण परीक्षण चलाएँ

• Windows पर एंड-टू-एंड संगतता चलाएँ

• मल्टी-होस्ट ऑडिट — एक कॉल में कई SSH प्रोफ़ाइलों में स्वास्थ्य की तुलना करें

• मौजूदा ~/.ssh/config से प्रोफ़ाइल आयात करें

• बड़ी फ़ाइलों और अस्थिर कनेक्शनों के लिए फिर से शुरू करने योग्य स्थानांतरण

• दूरस्थ संचालन समयरेखा — एक ऑडिट ट्रेल में कमांड, स्थानांतरण और गार्ड निर्णय

• तैयार SSH समस्या निवारण प्लेबुक

• शेल में गए बिना कंटेनर लॉग — पूर्ण: ssh_log_tail और ssh_log_search एक कंटेनर नाम लेते हैं, docker से पूछते हैं कि वह कहाँ लिखता है और उस फ़ाइल को किसी अन्य लॉग के समान तंत्र से पढ़ते हैं

• एक अस्वीकृति जो आपको फँसा देती है — पूर्ण: हर सीमा अब ssh_exec को रास्ते के रूप में नाम देती है, इसलिए किसी उपकरण के किनारे पर पहुँचने पर एक वाक्य खर्च होता है, अनुमान लगाने के खेल के बजाय

• उत्तर जो मॉडल तक पहुँचते हैं — पूर्ण: कमांड आउटपुट, मिलान लॉग पंक्तियाँ, मशीन नाम और स्नैपशॉट अनुभाग फ़ील्ड में यात्रा करते हैं, केवल पाठ में नहीं

• छोटे MCP उपकरण स्कीमा — पूर्ण: उपकरण सूची 10% हल्की हो गई, और एक अलग कार्य अब अंधेरे में पोल किए जाने के बजाय अपनी अंतिम पंक्तियाँ दिखाता है

• रूट के अधीन लंबा कार्य — पूर्ण: एक अलग कार्य sudo के साथ चलता है और रूट के रूप में अनुसरण किया जाता है, और एक कुंजी-केवल प्रोफ़ाइल sudo का उत्तर अपने स्वयं के sudoPassword से देती है

SSH MCP सर्वर विकसित और परीक्षण करें

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 देखें।

SSH MCP सर्वर पसंद है? ⭐

यदि आपको उपकरण पसंद है, तो GitHub पर इसे स्टार दें — यह अधिक लोगों को प्रोजेक्ट खोजने में मदद करता है।

SSH MCP सर्वर में योगदान करें

मुद्दे और पुल अनुरोध github.com/hypnosis/ssh-mcp-server पर स्वागत हैं।

लाइसेंस

MIT — LICENSE देखें।