Hermes Agent に、鍵を渡さずサーバーへの SSH アクセスを与える

2026年10月15日 · Termalin Team ai-agentsmcpsshsecuritytutorial

Hermes Agent はすでに、リモートのマシンでシェルコマンドを実行します。その SSH ターミナルバックエンドは 1 台のホストを指し、各コマンドを ssh 越しに実行します。サーバーが 1 台ならそれで十分です。ところが 2 台以上になった瞬間、あるいはエージェントを動かすマシンに秘密鍵を置きたくないとなると、このバックエンドは適切な道具ではありません。もっときれいな構成は、Hermes を、代わりにあなたのサーバーへ到達するリモート MCP サーバーにつなぐことです——エージェントのマシンに鍵はなく、多数のホスト、接続ごとのルール、そして監査ログが手に入ります。この記事は両方を扱います。SSH バックエンドが今どう動くか、そして代わりに Termalin を MCP サーバーとしてどう配線するか、です。

開示：Termalin を作っているのは私たちです。以下の Hermes Agent に関する詳細は、2026 年 10 月 15 日に確認した公開ドキュメントと issue トラッカーに基づいています。

Hermes Agent は今 SSH をどう使うか

Hermes Agent は、ツールをターミナルバックエンドを通じて実行します。そのバックエンドの 1 つが SSH です。~/.hermes/config.yaml で設定します。

terminal:
  backend: ssh

認証情報は ~/.hermes/.env に置きます。

TERMINAL_SSH_HOST=my-server.example.com
TERMINAL_SSH_USER=ubuntu

TERMINAL_SSH_PORT は既定で 22、TERMINAL_SSH_KEY は秘密鍵へのパスです（空のままにするとシステムの既定が使われます）。ドキュメントはこの仕組みを率直に説明しています。「リモートサーバーで SSH 越しにコマンドを実行する」、ControlMaster と 5 分のアイドルキープアライブで接続を使い回す、そして各コマンドは毎回新しい ssh … bash -c である、と。

この設計から 3 つの事実が導かれ、それらが人々がほかを探し始める理由になっています。

1 つのバックエンドは 1 台のホストを意味します。 TERMINAL_SSH_HOST と TERMINAL_SSH_USER はどちらも必須で、このバックエンドには複数ホストのインベントリがありません。2 台目のサーバーを扱うには、設定し直すことになります。
秘密鍵が Hermes のマシンに置かれます。 ファイルとして、あるいはシステムの ssh-agent 経由で。そのマシンを読めるものなら何でも鍵を使えますし、その鍵は、それを信頼するすべてのホストを開きます。
Hermes は自分の認証情報をリモートのマシンにコピーします。 ドキュメントによれば、SSH・Modal・Daytona の各バックエンドでは、Hermes がセッションのあいだ、あなたの ~/.hermes/ の状態——認証情報ファイル、スキル、キャッシュ——をリモートのサンドボックスへ送り込み、終了時に変更された状態ファイルを同期して戻します。

ドキュメントは SSH バックエンドについて、もっともな主張もしています。エージェントが別のマシンで動くため、「自分自身のコードを書き換えられない」というものです。その隔離は本物で、この点には後で立ち返ります。

人がぶつかる問題

hermes-agent のトラッカーには、こうした SSH 周りのオープンな issue が、はっきりと見てとれるかたまりで並んでいます。それぞれがあなたにとって何を意味するかを過大に語らず、番号で挙げます。

名前付きプロファイルを使うと、SSH バックエンドが「path too long for Unix domain socket」で失敗する（#133436）。
設定変更後、/reload がキャッシュされた SSH 環境をクリアしない（#71085）。
デスクトップの SSH モードには独自の一式があります。約 1 秒で失敗する macOS のプローブ（#80836）、Windows OpenSSH のハングとタイムアウト（#118983、#138378、#127320）です。
起動時のリトライ嵐で、1 分あたりおよそ 25 回の SSH ログインが起きる（#134197）。
22 番ポートをブロックするネットワークで hermes update が失敗する（#133439）。

このうちいくつかはバックエンドではなくデスクトップアプリに関するもので、あなたが読む頃にはすでに解決済みのものもあるかもしれません。大事なのはパターンです。SSH バックエンドは 1 本の ssh 接続の薄いラッパーなので、その接続の鋭い角をすべて受け継ぎます——22 番ポートに到達できる必要がある、という点を含めて。

鍵なしの代替：リモート MCP サーバーとしての Termalin

Hermes Agent は MCP に対応しています。stdio サーバーともリモートの HTTP サーバーとも、Bearer ヘッダーか OAuth のどちらかで話せます。そこが突破口です。エージェントに鍵と 1 台のホストを与える代わりに、あなたのサーバー群への到達方法をすでに知っているリモート MCP サーバーへ向けます。

Termalin は、ホスト型の MCP サーバーを備えた SSH クライアントです。到達可能にしたいサーバーごとに Connector を動かします——1 行でインストールでき、外向きにダイヤルし、ポートを待ち受けることは決してないので、NAT や CGNAT の内側でも動き、22 番ポートを開ける必要もありません。登録時に、サーバーの sshd は Termalin の SSH 認証局を信頼します。以降のログインはすべて、あなたのアカウントにスコープを絞った短期証明書を使います。長期の鍵はマシンに残らず、エージェントに渡されるものもありません。

MCP サーバーは、~/.hermes/config.yaml のトップレベルの mcp_servers キーの下に置きます。認証には 2 通りあります。Hermes がよく動く場所である VPS では、API キーのほうが簡単なので、そこから始めます。

オプション A——API キー（VPS に最適）

Termalin のウェブキャビネットで API キーを作り、このエージェントが触れてよいサーバーにスコープを絞り、読み取り専用または許可リストに設定し、有効期限を与えます。それを ~/.hermes/.env に置きます。

TERMALIN_API_KEY=tk_live_your_key_here

次にサーバーを追加します。Hermes は ${VAR} の参照を、headers の内側も含め、サーバー接続時に解決します。

# ~/.hermes/config.yaml
mcp_servers:
  termalin:
    url: "https://termal.in/api/v1/mcp"
    headers:
      Authorization: "Bearer ${TERMALIN_API_KEY}"

接続を確認し、それからセッション内で MCP を再読み込みします。

hermes mcp test termalin

/reload-mcp

url サーバーの既定トランスポートは Streamable HTTP で、termal.in が話すのもそれなので、transport: の行は要りません。

オプション B——OAuth サインイン（ノート PC 向け）

Hermes がブラウザーのある自分のマシンで動くなら、OAuth なら鍵を保存せずに済みます。

# ~/.hermes/config.yaml
mcp_servers:
  termalin:
    url: "https://termal.in/mcp"
    auth: oauth

hermes mcp login termalin

初回接続時、Hermes は認可 URL を表示し、可能ならブラウザーを開き、ローカルのループバックポートで OAuth コールバックを待ちます。Termalin のサインインはそのループバックのリダイレクト（http://127.0.0.1:<port>/callback）を受け付けるので、私たちの側では auth: oauth が動きます。

ヘッドレスの VPS では、ループバックのコールバックはあなたのノート PC に届きません。Termalin で使える回避策は 2 つあります。リダイレクト URL を Hermes のプロンプトに貼り戻すか、ssh -N -L <port>:127.0.0.1:<port> user@host でポートを転送し、ノート PC のブラウザーでサインインを仕上げるかです。Hermes にはデバイスコードフローもありますが、Termalin のサインインはそれを提供していません。サーバー上では、オプション A の API キーのほうが簡単な道筋です。

つないだあとに得られるもの

hermes mcp test termalin（または hermes mcp login termalin）と /reload-mcp のあと、Termalin のツールがエージェントに現れます。到達してよいサーバーを見る hosts_list、1 台または複数でコマンドを実行する ssh_exec と ssh_exec_many、ファイル用の sftp_list / sftp_read / sftp_write、健全性のための server_metrics と alerts_list、そして 1 回の呼び出しより長く続く作業のための job_start / job_status / job_stop / job_list です。

SSH バックエンドとの実用上の違いです。

一度に多数のサーバー。 ssh_exec_many は、同じコマンドを一群のホストにまたがって実行します。1 台に限る制約も、マシンを切り替えるための設定し直しもありません。
接続ごとのルール。 「AI アプリ」カードで、この接続にコマンドポリシーを設定します。フルアクセス、許可リスト、または読み取り専用です。読み取り専用から始め、あとで広げます。
監査ログ。 エージェントが実行するすべてのコマンドは、エージェントのものとしてタグ付けされ、記録され、ライブのウォッチグリッドに表示されます。「エージェントがこれをやった」は、再構成ではなくフィルターです。エージェントの操作を監査する（英語）を参照してください。
バックグラウンドジョブ。 長いマイグレーションやビルドはジョブとして走るので、遅い処理がセッションをふさいだり、固定のタイムアウトに当たったりしません。
開放ポートなし。 Connector は外向きにダイヤルするので、「22 番ポートがブロックされている」種の問題も回避できます。

アクセスの取り消しはトグル 1 つで、全ホストにまたがる鍵のローテーションではありません。このトレードオフの背後にある理屈については、エージェントに SSH 鍵を渡すべきでない理由（英語）と影響範囲（ブラスト半径）をご覧ください。

代わりに SSH バックエンドを使い続けるべきとき

これは、1 つの選択肢がすべての項目で勝つような話ではありません。

マシンがちょうど 1 台で、すでに Hermes のマシンに鍵を置いていて、間にほかの何も挟みたくないなら、SSH バックエンドがいちばん手間が少ない選択です。
ドキュメントの隔離という論点は成り立ちます。別のホストで動かすということは、エージェントが自分のコードを書き換えられないということです。MCP の道筋もその性質を保ちます。コマンドが実行されるのはエージェントのマシンではなく、あなたのサーバー上だからです——ただし SSH バックエンドですでにそれが得られ、それ以上が必要ないなら、乗り換える理由はありません。
Termalin の MCP と監視ツールには、Pro プラン（$10/月、または年払いで $8/月、$96/年）か 14 日間のトライアル、そして各サーバーの Connector が必要です。鍵 1 本と SSH バックエンドなら費用はかかりません。

サーバーが複数あるとき、エージェントのマシンに鍵を置きたくないとき、サーバーが NAT の内側にあるとき、あるいは接続ごとのルールと監査証跡が必要なときは、Termalin を使ってください。1 台のホストに 1 本の鍵で本当に事足りるなら、SSH バックエンドのままで構いません。

トラブルシューティング

ツールが出てこない。 hermes mcp test termalin を実行し、url が正しいこと、TERMALIN_API_KEY が ~/.hermes/.env に設定されていることを確認します。それからセッション内で /reload-mcp します。
エンドポイントから 401。 API キーが無い、間違っている、または期限切れです。キャビネットで新しいものを作り、~/.hermes/.env を更新します。
${TERMALIN_API_KEY} の参照がそのまま送られる。 Hermes は ${VAR} を接続時に展開します。その変数が ~/.hermes/.env（または Hermes を起動したシェル）にあることを確認し、つなぎ直します。
ヘッドレス VPS で OAuth が完了しない。 ループバックのコールバックがノート PC に届きません。ssh -N -L <port>:127.0.0.1:<port> user@host でポートを転送するか、リダイレクト URL をプロンプトに貼り戻します。サーバー上では、API キーの道筋のほうが簡単です。
トランスポートの誤り。 url サーバーの既定は Streamable HTTP で、termal.in はこれを使います。transport: sse は、SSE しか話さないサーバーにだけ設定してください——このサーバーには不要です。

よくある質問

Hermes Agent は MCP に対応していますか？ はい。stdio サーバーとリモートの HTTP サーバーに、Bearer ヘッダーか OAuth で接続し、~/.hermes/config.yaml の mcp_servers の下に設定します。

VPS 上の Hermes Agent でこれを使えますか？ はい。そこでは API キーの道筋が最も簡単です。OAuth フローにはブラウザー、または上のヘッドレス用の回避策のいずれかが必要です。

サーバーでポートを開ける必要はありますか？ いいえ。Connector は外向きにダイヤルするので、NAT や CGNAT の内側でも、受信ポートなしで動きます。NAT 越しの SSH（英語）を参照してください。

私の SSH 鍵はエージェントに渡されますか？ いいえ。サーバーへは、ログインごとに発行される短期証明書で到達します。長期の鍵が Termalin から出ることはなく、エージェントの環境に置かれるものもありません。

Termalin は、ホスト型の MCP サーバー、鍵カストディアン（あなたの代わりに鍵を預かり、署名する仕組み）、そしてホストごとのエージェントポリシーを備えたクロスプラットフォームの SSH クライアントです。別のエージェントを使っていますか？同じ鍵なしの構成は、OpenClaw、Codex（英語）などでも使えます。あるいはアプリをダウンロードして始めてください。