RFC 4251: SSHアーキテクチャ

このRFCが決めたこと

横にスクロール

RFC 4251（2006年1月）は、SSH（Secure Shell）プロトコル・バージョン2の全体像を定めたアーキテクチャ文書だ。SSHは1995年、大学のネットワークでパスワードが盗聴された事件を機にTatu Ylönenが開発した遠隔ログインツールに始まる。初期の実装（SSH-1）には設計上の弱点があり、IETFでの標準化を経て再設計されたのがSSH-2で、その仕様が2006年1月発行の一連のRFCに分割されて収められている。

4251自身はプロトコルの詳細を定めない。用語・データ表現・脅威モデルといった共通の前提を整理し、詳細を3つの姉妹文書に委ねる構成だ。トランスポート層プロトコル（RFC 4253）がサーバー認証・暗号化・完全性保護を、ユーザー認証プロトコル（RFC 4252）がユーザーの認証を、コネクションプロトコル（RFC 4254）がチャネルの多重化を受け持つ。

要点の精読

3層の積み木構造

SSH-2は3つのプロトコルが積み重なった構造をしている。最下層のトランスポート層は、通常TCP（TCPとUDP）のポート22の上で動き、鍵交換・サーバー認証・暗号化・完全性保護を提供する。その上でユーザー認証プロトコルが「誰が接続しているのか」を検証し、最後にコネクションプロトコルが実際の作業の通り道となるチャネルを提供する。

この積み順が重要だ。まずサーバーが本物であることを確かめ、通信路を暗号化してから、ユーザーの認証情報を送る。パスワードが平文でネットワークを流れないことは、順序の設計そのものによって保証されている。

ホスト鍵によるサーバー認証とTOFU

各サーバーはホスト鍵という鍵ペアを持ち、クライアントはこれでサーバーの真正性を検証する。RFC 4251は信頼の置き方として2つのモデルを示す。1つはクライアントがホスト鍵をローカルのデータベース（実装ではknown_hostsファイル）に記録して照合する方式、もう1つは認証局（CA）がホスト鍵を証明する方式だ。現実に広く使われているのは前者で、初回接続時にフィンガープリントを確認して受け入れ、以後はその鍵との一致を検証し続ける。この運用はTOFU（Trust On First Use）と呼ばれる。

The authenticity of host 'example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

この警告は儀式ではなく、信頼の起点そのものだ。yesと答えた瞬間に「このフィンガープリントのサーバーを本物とみなす」という約束が結ばれる。2回目以降に鍵の不一致が検出されれば、クライアントは中間者攻撃の可能性を示す強い警告を出して接続を拒む。

鍵交換とセッション鍵

トランスポート層では、接続の最初にクライアントとサーバーが鍵交換（Diffie-Hellmanなど）を行い、盗聴者には計算できない共有秘密を作る。そこから方向別の暗号鍵とMAC鍵が導出され、以後のパケットはすべて暗号化と完全性検証の対象になる。ホスト鍵は鍵交換の途中でサーバーが署名を返すために使われるので、「通信路の暗号化」と「相手が本物であること」が一度の手続きで同時に成立する。長時間の接続では再鍵交換も規定されており、同じセッション鍵を使い続けない。

チャネル — 1本の接続を多重化する

コネクション層の中心概念がチャネルだ。認証を終えた1本のSSH接続の上には、複数の独立したチャネルを同時に開ける。対話シェルも、リモートコマンドの実行も、SCPやSFTPによるファイル転送も、ローカル／リモートのポート転送も、それぞれが1つのチャネルとして同じ暗号化された接続を共有する。各チャネルはウィンドウによるフロー制御を持ち、大きなファイル転送が対話シェルの応答性を潰さないよう設計されている。

ポート転送が特別な機能に見えるのは錯覚で、プロトコル上は数あるチャネル種別の1つにすぎない。この見方ができると、X11転送が同じ枠組みで実現されている理由も自然に理解できる。

TLSと何が違うのか

同じ「暗号化された通信路」でも、TLS（RFC 8446: TLS 1.3）とは信頼の設計思想が異なる。TLSは不特定多数のクライアントが初対面のサーバーを検証できるよう、認証局の連鎖に信頼を預ける。一方SSHは、管理者が特定のサーバーへ繰り返し接続する用途を想定し、CAを必須とせず、最初の確認と継続的な同一性検証（known_hosts）に信頼を置く。どちらが優れているかではなく、Webと遠隔管理という用途の違いが信頼モデルの違いを生んでいる。

つまずきやすい点

最大の落とし穴は、初回接続のフィンガープリント確認を惰性でyesと打つことだ。TOFUは「初回だけは無防備」というモデルであり、その初回に中間者がいれば偽サーバーの鍵を信頼してしまう。重要なサーバーでは、コンソールなど別経路で ssh-keygen -lf により得た正しいフィンガープリントと照合してから受け入れるべきだ。同様に、既知のサーバーで鍵不一致の警告が出たとき、深く考えずknown_hostsの該当行を消して繋ぎ直すのは、攻撃の兆候を自ら握り潰す行為になりうる。

認証方式の選択も定番のつまずきだ。password認証は正しい相手に対してさえ秘密そのものを送信するため、接続先を誤れば秘密が漏れる。publickey認証では秘密鍵は手元を離れず、サーバーへは署名だけが渡るので、総当たりにも漏洩にも構造的に強い。多くの現場がパスワード認証を無効化して公開鍵認証へ寄せるのは、この差が理由だ（セキュリティの各記事も参照）。

まとめ

RFC 4251は、SSH-2という積み木の設計図だ。トランスポート層（RFC 4253）がサーバー認証と暗号化を、ユーザー認証層（RFC 4252）が本人確認を、コネクション層（RFC 4254）がチャネル多重化を担い、信頼はCAではなくホスト鍵とTOFUに置かれる。この全体像を持って初回接続の警告を読み直せば、yesの一打が持つ重みは変わるはずだ。他のプロトコルの精読はRFC精読から辿れる。