SSHの仕組み — 接続先と自分を、別々に確かめる
サーバーの鍵と、自分の鍵を分ける
まずは、2種類の鍵を分ける
サーバーのホスト鍵は接続先が誰か、利用者の公開鍵認証は自分が誰かの確認に使います。どちらも鍵が登場しますが、同じ記録ではありません。
| 確認 | よく見る場所 |
|---|---|
| 接続先のホスト鍵 | 手元のknown_hosts、管理者からのフィンガープリント |
| 利用者の公開鍵 | サーバーのauthorized_keys等 |
| 利用者の秘密鍵 | 手元の鍵ファイルやエージェント等 |
自分が管理する公開鍵ファイルがあるなら、OpenSSHの次の読み取り操作で要約を見られます。例のファイル名は手元の公開鍵に置き換えます。
ssh-keygen -l -E sha256 -f demo_key.pub
表示は鍵のビット数、SHA256の値、コメント、種類等です。これは公開鍵の要約を見る操作で、接続先の正当性やログイン成功を確かめたことにはなりません。初回接続の画面では、サーバー管理者等から別の信頼できる経路で取得したホスト鍵の値と比べます。
接続の中で行うこと
- TCPで接続し、SSHのバージョンや対応する方式を交渉する。
- 鍵合意とホスト鍵を使う認証等で、暗号化した通信を確立する。
- パスワードや公開鍵等の方法で利用者を認証する。
- 許可されたシェル、コマンド、転送等を使う。
公開鍵認証では、クライアントがセッション識別子と認証要求の内容等へ秘密鍵で署名し、サーバーが署名とその鍵の利用許可を確認します。「サーバーが送った乱数だけへ署名する」という説明では、接続への結び付きが抜けます。
踏み台・転送・鍵の管理
ssh -J bastion targetは踏み台を経由する指定です。実際のホスト名・利用者・アクセス権が必要です。-Lは指定した接続のローカル転送、-DはSOCKSの接続口を作ります。後者でも、アプリがそのSOCKSを使わなければ通信は通りません。
ssh-agentは鍵での署名を助けます。エージェント転送先の権限を持つ人に署名を悪用され得るため、必要性と接続先を判断します。秘密鍵のファイルを転送しないことと、悪用されないことは別です。SSH CAは証明書での管理の選択肢で、すべての大規模環境に必須というわけではありません。
もう少し詳しく:鍵合意の更新
OpenSSHは9.0でsntrup761とX25519のハイブリッドを既定とし、9.9でML-KEMの方式を追加、10.0でmlkem768x25519-sha256を既定にしました。10.1では非耐量子の鍵合意に警告を出す挙動が加わっています。ホスト鍵や利用者の署名まで全部同じ耐量子方式へ変わったという意味ではありません。
🐧 ペンギン先生のまとめ:「SSH」って出てきたら「相手を確かめて、遠くのコンピューターを暗号化した通信で使う仕組み」と思えばだいたいOK!
鍵の役割は暗号化の仕組み、接続の入口はTCPの仕組みで確認できます。
参考資料
- OpenSSH:ssh — ホスト鍵・転送・エージェント・ProxyJump
- OpenSSH:ssh-keygen — 公開鍵のフィンガープリント表示
- IETF:RFC 4252 — 公開鍵認証の署名対象とセッションへの結び付き
- OpenSSH:Post-Quantum Cryptography — 耐量子ハイブリッド鍵合意の導入・既定・警告