要約

  • RFC 9987は、秘密鍵を保持し、鍵の追加・削除・一覧・ロック・署名要求に応答するSSHエージェントのプロトコルを定める。基本プロトコル自体には認証もトランスポート保護もなく、接続点への到達が実質的な呼び出し権になる。
  • エージェント転送は秘密鍵素材をリモートへ複製しない。代わりに秘密鍵操作を要求する経路をSSH接続の先へ延ばすため、RFCが明記する推移的信頼が生じる。
  • 有効期間、操作ごとの確認、拡張制約は呼び出し能力を狭める。ただし宛先サーバーは鍵と署名をアカウント用に受理するか、追加認証やチャネルをどう扱うかを独立に決める。

運用担当者が踏み台からログアウトした。監視画面はセッション終了を示し、端末上の秘密鍵も一度も踏み台へコピーされていない。そこでインシデントが終わったと判断したくなる。

しかし、エージェントへの転送接続が同じ瞬間に消えたとは限らない。RFC 9987は、SSHクライアントが自身の認可に従い、事前のセッション要求なしにエージェント接続を受け入れる場合や、転送を求めたセッション終了後も受け入れ続ける場合を許容する。正当な構成を支える柔軟性だが、シェルの寿命を署名能力の寿命とみなすことはできない。

この時間差が、秘密鍵保管の監査を権限監査へ変える。

秘密を置く場所と、秘密を使える場所

SSHエージェントの利点は大きい。各クライアントが復号済み秘密鍵を保持せず、専用プロセスが暗号処理を担う。パスフレーズ入力を繰り返さずに済み、ハードウェアトークン内の鍵を利用できる。メモリダンプやデバッグを制限した小さなコンポーネントに鍵操作を集約することもできる。

RFC 9987は2026年5月にProposed Standardとして公開され、こうしたエージェントとの共通メッセージを定義した。クライアントがすべての要求を開始し、エージェントは勝手に通知せず順番に応答する。鍵の種類や状況によって拒否してもよい。

重要なのは、プロトコル内にクライアント認証とトランスポート保護がないことだ。Unix系ではソケットの権限や対向プロセスの資格情報、Windowsではnamed pipeのセキュリティ記述子が境界になる。SSH_AUTH_SOCK は接続先を発見させる。

したがって、鍵がどのディスクにあるかだけでは権限面を描けない。誰がソケットへ接続できるか、どのプロセスが代理操作を頼めるかが、鍵の実効的な利用面になる。

RFCは、鍵そのものの窃取を防げても、鍵の使用を盗まれる可能性は残ると区別している。非エクスポート鍵は将来の持ち出しを難しくする。だがオンライン中の署名オラクルへの到達を自動的には止めない。

署名成功が意味する範囲

秘密鍵操作では、クライアントが公開鍵blob、署名対象データ、フラグを送る。エージェントが成功すれば署名を返す。ここで立証されたのは、指定鍵がその入力に対して操作を行ったことだ。

要求元プロセスが人間の代理権を持つこと、入力が承認済み宛先を表すこと、サーバーがその鍵を受け入れること、コマンドが実行されたことはまだ分からない。暗号学的に正しい結果を、組織的な承認へ自動昇格させてはならない。

SSH公開鍵認証では、RFC 4252が署名対象を具体化する。session identifier、ユーザー名、サービス、認証方式、アルゴリズム、公開鍵が一つの要求に結ばれる。宛先サーバーは鍵がそのユーザーの認証子として許されているか、署名が正しいかを別々に検査し、さらに別方式を求めることもできる。

この結合により、あるセッション用署名をそのまま万能パスワードとして使い回すことはできない。一方、エージェントへの生きた経路があれば、攻撃者は別の正しい認証要求に対する新しい署名を依頼できる。過去署名の再利用防止と、オンライン能力の濫用防止は同じではない。

制約は設定名ではなく状態遷移

有効期間制約は、鍵を追加してから指定秒数後にエージェントが削除するよう求める。将来の署名窓を閉じるが、発行済み署名、成立済みセッション、実行済み操作は取り消さない。

確認制約は、秘密鍵操作ごとに明示的な確認を求める。RFCは表示内容や人間向けUIを規定しない。宛先とアカウントを示す低頻度の確認と、鍵コメントだけを出す大量プロンプトでは、同じ「確認済み」でも証拠価値が違う。

拡張制約は実装固有のルールを追加できる。エージェントが理解できない制約に出会った場合、安全に読み飛ばせないため、解析を中止して鍵追加を拒否しなければならない。制限を黙って無視しない、望ましいフェイルクローズだ。

ただし、制約は固定属性ではない。同じ鍵を再追加すると、新しい要求の制約で以前の制約を置き換えるべきだとRFCは述べ、あるいは重複を拒否してよいとする。ツールの切り替えや再ログインで、確認付き短期鍵が無制約へ変わる可能性がある。証拠は各追加後の実効状態を読む必要がある。

ロックは秘密操作を停止する。ローカルagentを閉じる措置としては有効だが、遠隔サーバーが既に認証したセッションまで巻き戻す機能ではない。

転送が作る推移的信頼

エージェント転送では、リモート側のsocketに入ったagentメッセージがSSHチャネル経由でクライアント側agentへ届く。秘密鍵素材は移動しない。その代わり、リモートホストは秘密鍵操作を呼べる。

RFC 9987はこれを本質的な推移的信頼関係と呼ぶ。実装は既定で転送すべきではなく、利用者は完全には信頼しないホストへ転送すべきではない。転送接続ごとの鍵可視性や利用制限がなければ、選択は事実上すべてか無かになる。

踏み台を信頼するとは、ホスト鍵を検証したという意味だけではない。socketへ到達できる特権プロセス、管理者、プラグイン、同居ワークロード、供給網、侵害検知を信頼することでもある。入口を一箇所に絞る装置が、複数環境の署名能力を集める場所にもなる。

一つのSSH transportは複数sessionを多重化でき、同じagentへの接続も並行し得る。agent-connect には発生元session channelを識別する情報がない。よって「このシェルがこの署名を求めた」という結論は、プロトコル形状だけからは出ない。

外側接続、転送要求、agent channel、鍵指紋、制約判断、署名時刻、宛先認証結果を相関する必要がある。時計と接続IDが揃っていなければ、署名とログインが同時に見えても因果を確定できない。

実行可能な証拠をつなぐ

起点ではagentプロセス、接続点権限、対向資格情報、鍵指紋、追加時刻、実効制約、ロック、削除を記録する。トークン利用時は、プロバイダーライブラリのロードと隔離も対象だ。共有ライブラリのロードはコード実行面を増やすためである。

転送境界では、外側SSH接続、ホスト信頼判断、転送要求、全agent channelの開始・終了、session終了後に残った接続を記録する。明示設定、継承設定、互換性のための機会的要求も分ける。

署名境界では、時刻、鍵、アルゴリズム、署名文脈の安全なダイジェスト、制約結果、確認内容を保持する。機密データを無差別に残す必要はないが、宛先認証へ結合できる精度は要る。

宛先ではアカウント、許可鍵、署名検証、追加因子、開いたchannel、サーバー側制限を記録し、その後のコマンド、サブシステム、転送、ファイル操作を観測する。

終了も観測する。鍵削除、agent停止、転送channel閉鎖、宛先側許可の撤去を行い、新しい試行が失敗することを確認する。ローカル削除だけで全遠隔状態が消えたとは言えない。