要約

  • 最初の鍵交換は共有秘密Kと交換ハッシュHを生み、その最初のHが接続のセッション識別子になる。片方が自由に付ける名前ではない。
  • rekeyでは暗号方式、通信鍵、初期化ベクトル、圧縮状態、さらにはホスト鍵まで変更できるが、元のセッション識別子は変わらない。
  • 公開鍵認証の署名対象にはセッション識別子と利用者・サービス・方式・鍵が入る。別接続への再利用は防げるが、shellやポート転送の許可まで自動的に与えるわけではない。

会話の寿命と鍵の寿命を分ける

遠隔端末は長く使われ、ファイル転送や転送チャネルも状態を持つ。一方、パケットを保護する暗号鍵は、その活動が終わるまで固定する必要はない。むしろ途中で替える理由がある。

鍵を替えるたびに新しいセッションと扱えば、上位層はすべてを作り直すことになる。逆に新しい鍵だけを新しい身元と見なせば、更新前の利用者認証が更新後の通信にどう属するのか曖昧になる。

RFC 4251はSSH 2を三層に分けた。トランスポートはサーバーを認証し、機密性と完全性を提供する。その上で利用者認証が動き、さらに接続プロトコルがshell、サブシステム、転送用の論理チャネルを多重化する。rekeyが変えるのは第一層の保護であり、上位の会話そのものではない。

識別子は宣言ではなく計算結果だった

両端はSSH_MSG_KEXINITを送り、ランダムなcookieと、鍵交換・ホスト鍵・暗号・完全性・圧縮の候補を優先順に示す。条件を満たす共通候補のうち、クライアント側の順序で最初のものが選ばれる。

選ばれた方式は共有秘密Kと交換ハッシュHを計算する。SSH 2の元来の有限体Diffie–Hellmanでは、Hにクライアントとサーバーの識別文字列、両方のKEXINIT本体、サーバーホスト鍵、双方の一時値、共有秘密が入る。

したがって、バージョン、提案アルゴリズム、ホスト鍵、一時値のどれかが違えば、ハッシュの根拠も違う。Hはサーバーが発行する整理番号でも、クライアントが持ち込むラベルでもない。双方の実行記録が形を決める。

ランダムcookieは事前の決め打ちを難しくするが、セッション識別子自体は秘密ではない。公開されてもKは復元できず、正しい通信保護を作る資格にもならない。

サーバーは選ばれたホスト秘密鍵で交換ハッシュに署名する。検証成功が示すのは、その秘密鍵の保持者がこの交換記録へ署名したことだ。公開鍵が利用者の意図したホスト名に属するかは別の判断である。保存済みの対応、証明書、別経路で確認した指紋など、クライアントの信頼規則が必要になる。見知らぬ鍵による正しい署名は、正しい相手の証拠にはならない。

最初のHだけが接続を名乗った

RFC 4253では、各交換のKとHが新しい鍵やベクトルの導出に使われる。ただしsession_idになるのは最初のHだけで、一度決まれば後の鍵交換でも変化しない。

rekeyは小さな更新ではない。どちらからでも開始でき、アルゴリズムを替えられる。ホスト鍵も変わり得る。全通信鍵と初期化ベクトルを再計算し、SSH_MSG_NEWKEYSの境界で暗号・圧縮コンテキストを初期化し直す。それでもクライアントとサーバーの役割は継続し、セッション識別子は最初の交換を指したままである。

ここから「何も変わらなかった」と結論してはいけない。予期しないホスト鍵は新たな信頼判断を要し、弱い方式はポリシー違反になり、失敗すれば接続は終わる。不変なのは、更新に成功したトランスポートが上位セッションを勝手に新設しないという一点だ。

再接続は別である。新しい初回交換から別の識別子ができる。アプリケーションが作業を再開しても、それはSSHの暗号学的には後継接続であり、以前と同一のセッションではない。

利用者署名は接続と要求をまとめて覆った

RFC 4252のpublickey認証は、利用者名だけに署名しない。署名対象の先頭はセッション識別子で、その後にSSH_MSG_USERAUTH_REQUEST、利用者名、サービス名、方式名、真偽値、公開鍵アルゴリズム、公開鍵本体が続く。

ある接続で記録した署名を別の接続へ移すと、先頭の識別子が異なるため検証できない。利用者、サービス、方式、鍵を差し替えても署名内容が変わる。証明されるのは「この秘密鍵の保持者が、この接続で、この具体的な要求を承認した」という範囲である。

サーバーにはなお別々の判断がある。署名は正しいか。その鍵を申し出たアカウントに使ってよいか。追加の認証要素が必要か。数学的な成功一つで認証方針全体が完了するわけではない。

hostbased方式も同じセッション束縛を使い、クライアントホスト名やその側の利用者を追加する。ホスト秘密鍵の保有と、ホスト名の信頼、ログイン許可は同義ではない。

認証成功は全チャネルの包括許可ではない

SSH_MSG_USERAUTH_SUCCESSの後、要求されたサービスが始まる。しかし、対話shell、ファイル用サブシステム、ポート転送、認証エージェント、特定宛先への接続は、それぞれローカル方針の対象になる。

認証時点では、クライアントがまだどのチャネルを要求するか示していないことも多い。セッション識別子は、後の処理が正しい保護文脈を参照するためのものだ。一度の認証を、将来の全操作への委任状に変えるものではない。

監査でも同じである。識別子と「公開鍵認証成功」だけなら、ログインをトランスポートへ関連付けられる。どのコマンド、サブシステム、転送が許可されたかは、チャネル単位の記録がなければ分からない。

アルゴリズムは更新され、責任の境界は残った

2006年の選択肢を永久に固定することはできない。RFC 8332は、サーバーと利用者の認証向けにSHA-256／SHA-512を使うRSA署名を加えた。既存のRSA公開鍵形式を保ちながら、別のアルゴリズム名で署名手続を更新できた。鍵の材料、署名方式、署名対象は別の要素である。

RFC 9142は鍵交換方式の実装推奨を改め、SHA-1系からの移行を進めた。初回交換の方式が変わっても、そこで得た最初のハッシュが上位層の文脈になるという構造は維持できた。

ただし、弱い初回交換を正確に参照しても強くはならない。誤ったホスト鍵を信じた場合や不適切な方式を許した場合、固定識別子は後の証明をその誤りに忠実に結び付ける。継続性は品質保証ではない。

同じ「SSHの身元」に見える五つの対象

ホスト名は意図した宛先、ホスト鍵はその名前と結ぶべき暗号主体、交換ハッシュは一回の交渉記録、最初のハッシュは一接続の文脈、利用者鍵は特定要求への保有証明である。操作を許可するのはさらに別のローカル方針だ。

RFCが示すのはこれらの意味とアルゴリズムの変遷であり、個別クライアントの鍵確認、rekeyの実施頻度、SHA-1の利用率、実行コマンドを証明するものではない。

SSHが残したのは、控えめな不変条件だった。保護する鍵は替えられる。しかし後の証明は、会話を成立させた最初の交換を忘れない。ハッシュは権限ではなく、証拠が戻る座標になった。