SSHハンドシェイクとホスト鍵認証

SSHはポート22へのTCP接続から始まります。接続が確立すると、クライアントとサーバーはSSH-2.0-OpenSSH_9.3のようなバージョン文字列を交換します。これはプロトコルのバージョンと実装を識別するものです。このバージョン交換により、双方は処理を続行する前に互換性を確認できます。

バージョン交換の後、双方はサポートしているアルゴリズムを列挙したSSH_MSG_KEXINITパケットを送信します。これらのリストには、鍵交換方式、ホスト鍵の種類、対称暗号、MACアルゴリズム、圧縮方式が含まれます。双方のリストの共通部分によって、そのセッションで使用するアルゴリズムが決まります。

セッション鍵は、Diffie-HellmanやECDHなどの鍵交換アルゴリズムを使って確立されます。クライアントとサーバーはそれぞれ一時的な鍵ペアを生成し、公開値を交換して、同じ共有秘密を独立して計算します。この共有秘密はセッション鍵の導出に使用されますが、直接送信されることはありません。

サーバーは、ホスト秘密鍵を使って鍵交換ハッシュに署名することで、自身の身元を証明します。ホスト鍵には、RSA、ECDSA、または最新のEd25519形式を使用できます。クライアントは対応する公開鍵でこの署名を検証し、偽装者ではなく正規のサーバーと通信していることを確認します。

新しいサーバーに初めて接続するとき、クライアントはまだホスト公開鍵を認識していません。SSHは鍵のフィンガープリントを表示し、ユーザーに受け入れるかどうかを尋ねます。このTrust On First Useモデルでは、鍵をknown_hostsに保存し、以降の接続で変更を検出して、中間者攻撃の可能性を警告します。

新しいサーバーのホスト鍵を検証する最も安全な方法は、帯域外のチャネルを利用することです。管理者がサーバーのフィンガープリントを対面または検証済みの安全なチャネルで伝え、それをSSHクライアントに表示されたものと比較します。これにより、初回接続時に不正な鍵を気付かず受け入れることを防げます。

known_hostsファイルには、hostname algorithm base64-keyという形式の行が保存されます。各エントリは、信頼されたサーバーの身元を表します。known_hostsに登録済みのホストへ接続すると、SSHは提示された鍵が保存済みの鍵と一致することを検証し、一致しない場合は接続を拒否します。

鍵交換の後、双方は共有秘密、交換ハッシュ、セッション識別子を使って、それぞれ独立してセッション鍵を導出します。通信の各方向と、暗号化処理およびMAC処理に対して、それぞれ別の鍵が導出されます。つまり、クライアントからサーバーへの通信で使う鍵と、サーバーからクライアントへの通信で使う鍵は異なります。

セッション鍵が確立されると、それ以降のSSH通信はすべて暗号化および認証されます。AES-256-GCMやChaCha20-Poly1305など、ネゴシエーションで選択された暗号が機密性を保護し、MACが完全性を保証します。ユーザー名や認証情報も、この暗号化トンネルの内部で送信されます。

2048ビットまたは4096ビットのRSAホスト鍵は広くサポートされていますが、処理速度は遅くなります。NIST曲線に基づくECDSA鍵は高速ですが、NIST曲線のパラメータを信頼しない人もいます。Curve25519に基づくEd25519鍵は、現代的な推奨方式です。サイズが小さく高速で、高い安全性を備え、NIST曲線のパラメータに依存しません。最新のSSHサーバーの多くは、デフォルトでEd25519を提供します。

SSHハンドシェイクは、TCP接続、バージョン交換、アルゴリズムネゴシエーション、セッション鍵を確立する鍵交換、サーバーホスト鍵の検証、ユーザー認証という流れで進みます。バージョン交換以降のすべての手順は、鍵交換フェーズで確立された、暗号化と完全性保護が施されたチャネル内で実行されます。

初回接続後、以降の接続でクライアントはどのようにSSHサーバーのホスト鍵を検証しますか？

このレッスンでは、ポート22でTCP接続を確立し、バージョン文字列を交換し、アルゴリズムネゴシエーションで暗号と鍵交換方式を選択し、ECDHまたはDHで共有秘密を確立し、通信方向ごとに個別のセッション鍵を導出する流れを学びました。さらに、サーバーはホスト鍵の署名で自身を認証し、クライアントは初回接続時にTOFUを使用してknown_hostsと照合します。