SSH MCP Server — AIエージェント向けリモートサーバーツール

お使いのマシンに既にあるOpenSSHクライアントを使用します：あなたのキー、~/.ssh/config、ジャンプホスト、エージェントフォワーディング。バンドルされるものはなく、コンパイルも不要、ネイティブバインディングもありません。

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

次に、少なくとも1台のマシンを指定して ~/.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+ と、PATH にシステムの ssh クライアントが必要です。Windowsではキーベースのプロファイルを使用してください。パスワードおよびパスフレーズのプロファイルは現在利用できません。

固定バージョンを好む場合、オフラインで作業する場合、または起動ごとのレジストリチェックを1回減らしたい場合は：npm install -g @hypnosis/ssh-mcp-server を実行し、npx の代わりに ssh-mcp-server コマンドを使用してください。

Related MCP server: ssh-mcp-server

こんな人におすすめ

• DevOpsおよびSRE — 監査、インシデントチェック、日常のサーバー作業を高速化したい方。

• Vibeコーダーやインディービルダー — AIアシスタントと一緒に開発し、自分たちのサーバーで構築したものを運用している方。

• システム管理者やプラットフォームエンジニア — 制限のない生のシェルではなく、構造化されたツールを求める方。

• 専任の運用チームなしで自前のVPSを運用する開発者や小規模チーム。

• ホームラボ、NAS、ルーターの所有者 — 便利なハードウェアが現代のプロトコルに対応しきれなくなった方。

生のシェルではなくSSH MCPサーバーを使う理由

トークン削減、AIコスト削減

生のシェルはAIエージェントに消防ホースのような情報の奔流を与えます：繰り返されるコマンド、ASCIIテーブル、ログのダンプ。そのノイズをサーバーの全体像に変換するためにトークンを消費します — つまりあなたのお金です。

より高速なサーバーデバッグ

専用ツールは日常的なチェックをまとめて実行し、ノイズの多い出力を制限し、重要な部分だけを返します。エージェントはターミナル出力の解釈に費やす時間が減り、より早く修正に到達できます。

推測の減少、AIのミス削減

構造化された回答は、何が見つかったか、何を測定できなかったか、何が切り詰められたかを示します。これにより、エージェントが幻覚でギャップを埋める余地が減り — 悪い修正が減り、デプロイが安定し、より信頼性の高いコードになります。

SSH互換性：最新サーバー、レガシー機器、Windows

既存のOpenSSH設定を使用

バンドルされたSSH実装はなく、ネイティブバインディングもなく、プラットフォームごとの再ビルドもありません。コマンドはシステムの ssh クライアントを使用するため、あなたのキー、~/.ssh/config、ジャンプホスト、エージェントフォワーディングはすべて、ターミナルで行うのとまったく同じように機能し続けます。サポートされている場合、宛先ごとに1つの共有マルチプレックス接続を使用するため、認証は1回だけで済み、コマンドごとには行いません。

レガシーサーバー、ルーター、NASデバイスへのSSHサポート

最新の 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 の結果は、いくつかの生のコマンド出力よりも長くなることがあります — 当社のラボ測定では約1,077トークン対765トークンです。節約は完全なワークフローから生まれるのであって、1つのレスポンスを短くすることからではありません。

実際のトラブルシューティングセッションでは、専用ツールによって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

3番目のコマンドはきれいに見えますが、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 は1回の呼び出しで複数のログから最後の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

終了コード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 には3つの重要なの結果があります: verified、サーバーにハッシュ ツールがない場合の unavailable、そして検証が要求されなかった場合の skipped です。 読み込みでは、ssh_file_read がパスのリストを受け取り、ssh_file_list はグロブ、 再帰、サイズ、モードを処理します。

sudo でバッチSSHコマンドを実行する

状況: デプロイの準備はできていますが、トラフィックを移す前に nginx の構文、 サービスの状態、最近のエラーをすべてチェックする必要があります。1件のチェック失敗が 結合ダンプの中に埋もれてしまっては困ります。

質問: 「すべての事前チェックは合格しましたか?」

素の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

3つの接続が、互いに関係のない出力を返します。コマンドを ; で結合した場合、シェルは 最後の終了コードしか報告しません。&& で結合した場合、最初の失敗より後のチェックは 消失します。

構造化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
}

エージェントが得る利点

破壊的コマンド保護は、最初のコマンドを実行する前にすべてのリストを検査します。 1つの項目が拒否された場合、他のすべての項目は「未実行」とマークされ、サーバーには何も 送信されません。

各コマンドは自身の stdout と stderr を持っています。実行して何も出力しなかった コマンドは空の文字列を支え、実行されなかったコマンドにはそれらのフィールド自体が存在 しません。したがって、2つの状態を読み違えることはありません。コマンドごとに128KBを 超える出力は、表向けの先頭とログ向けの末尾の両方を保持し、途中にちょうどカットした分量を 示す継ぎ目が入り、clipped_bytes がどれだけ切り出したかを示します。切り詰めは バイト境界で行われ、文字のエッジにどの戻るため、クリップされた応答の内容には置換文字が 混入しません。

sudo は、ターミナルなしでサーバーに到達します。プロファイルにパスワードがある場合は、 それが標準入力で sudo に渡されます。キーで認証するプロファイルはパスワードを持たない ため、その構成での sudo が機能するのはすでにパスワードレスの環境だけです。また、 自身の標準入力を読み取るコマンドにパスワードは決して渡されません。渡してしまうとデータに 混ざってしまうからです。

長時間実行される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_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
  }]
}

エージェントが得る利点

デバイスに 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 も検出します。

取り返しのつかない損失は拒否し、改善可能な変更には警告を出す

docker compose down -v は、-v が名前付きボリューム(データベースボリュームを含む)を 削除してしまうため拒否されます。-v がない場合にサービスを止める行為は、同じ取り返し のつかない操作としては扱われません。

ファイルシステムのルート、ホームディレクトリ、また /etc、/var、/usr のような システム系ディレクトリを再帰で――シンボリックリンク経由でも――削除できる操作も拒否されます。 rm -rf "$DIR"/* のように対象が解決できない操作も拒否されます。「確認できない」を 「安全」とみなさないからです。

破壊コマンドを意図したものとして確認する

永久に禁止されるものはありません。再確認済みのコマンドに # CONFIRMED-DESTRUCTIVE を 入れると、それが透しても通されるようにします。ガードがバッチ内のどこか一項目だけを拒否した 場合、バッチ全体が実行前に止まるため、サーバー上で操作の途中状態が残ることはありません。

ガードは1回の呼び出し単位で機能します。ある呼び出しの「削除」と次の呼び出しの「読み取り」 を繋いだり、自分が理解しないツールについて推測したりはしませんが、決してそれを意図しません。 これはポリシーエンジンではにシートベルトなって。復元ができる操作の判断はあくまで あなたの責任です。パスの制約と引用規則は docs/security.md にまとめています。

サーバー運用のためのSSH MCPツール

18のツール。全パターンと完全パラメータ的なは ** docs reference**docs/tools.md にあります。

MCPツールの安全関係注記

標準のMCPアノテーションは、どのツールが読み取り専用・破壊性テスト・で、処理が常に同じ か、それとも開いた世界を前提としているかをクライアントに伝えます。詳しい テーブル(ツール)参照 を 参照してください。

SSHコマンドの実行とリモートファイルの管理

長時間稼働するSSHジョブの監視

ログ検索とサーバーのヘルスチェック

SSH経由でファイルをアップロード / ダウンロード

バイナリセーフな転送 + 完全性チェック。詳細は docs/transfer.md に。

バイナリおよび大容量ファイルには ssh_upload / ssh_download を使用 — base64 やヒアドキュはクロマイナリセーフでもアトミックでもありません。

SSHでのLinuxサーバー監査

読み取り専用で、1回のラウンドトリップに大量にまとまります。詳しくは docs/audit.mdをご覧ください。

Windows での SSH 互換モード

Windows は互換モードを自動的に使用します。接続多重化が利用できない場合、サーバーはコマンドごとに1つの接続に切り替えます。同じツールが鍵ベースの 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 を参照してください。

SSH パスワードとパスフレーズをプロファイルに含めない

鍵を優先してください。パスワードまたは暗号化された鍵のパスフレーズが避けられない場合は、プロファイル自体ではなく、別のシークレットファイルに保存してください：

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

シークレットファイルはプロファイル名をキーにします — secrets.json.example を参照：

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

シークレットファイルは自分だけが読み取れるようにしてください（chmod 600）。相対パスはプロファイルファイルから解決されます。シークレットは argv の外に保持され、ログではマスクされます。認証情報のセキュリティ を参照してください。

Claude Code、Codex、その他の MCP クライアントの設定

使用するクライアントを選択し、同じプロファイルファイルを指定します。

Claude Code

1つのコマンドで、-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

他と同様、1つのコマンドです：

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

その他の MCP クライアント

Gemini CLI、Hermes、Cline、エディタプラグイン、または自作のエージェントも同様に動作します。必要なのは実行するコマンドと1つの環境変数だけです。

MCP クライアントの再起動

クライアントを再起動し、ssh_monitor({ action: "list" }) を実行してプロファイルが読み込まれたことを確認します。

SSH MCP サーバー設定

共有接続は意図的にこのプロセスより長く生存します。終了時に閉じると、同じマシン上の別のウィンドウが使用しているチャネルが切断されるためです。

SSH MCP サーバーの制限事項

• キャンセル： SSH を閉じるとリモートコマンドが実行中のままになる可能性があります。制御が重要な場合は、デタッチジョブを使用してください。

• アトミック書き込み： BSD と macOS では、ファイルシステムをまたいだリネームの事前チェックはできません。

SSH MCP サーバーのロードマップ

• macOS SSH ホストに対する完全なテスト実行

• Windows でのエンドツーエンド互換性テスト

• マルチホスト監査 — 1回の呼び出しで複数の SSH プロファイルの健全性を比較

• 既存の ~/.ssh/config からのプロファイルインポート

• 大容量ファイルと不安定な接続のための再開可能な転送

• リモート操作のタイムライン — コマンド、転送、ガード判定を1つの監査証跡に

• すぐ使える SSH トラブルシューティングのプレイブック

• モデルに届く回答 — 完了： コマンド出力、一致したログ行、マシン名、スナップショットセクションがテキストだけでなくフィールドでも送信されます

• より小さな MCP ツールスキーマ — 完了： ツール一覧が10%軽量化され、デタッチジョブはポーリングされる代わりに最後に書き込んだ行を表示するようになりました

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 各1つ）に対して実行されます。なぜなら、この2つは静かに食い違うことがあり、モックは作成者に合わせた結果を返すためです。レイアウトは docs/architecture.md を参照してください。

SSH MCP Server が気に入りましたか？ ⭐

このツールが気に入ったら、GitHub でスターを付けてください — より多くの人にプロジェクトを知ってもらう助けになります。

SSH MCP サーバーへの貢献

Issue とプルリクエストは github.com/hypnosis/ssh-mcp-server で受け付けています。

ライセンス

MIT — LICENSE を参照してください。