最終更新:

SSHの仕組み — 接続先と自分を、別々に確かめる


サーバーの鍵と、自分の鍵を分ける

① 接続先を確認サーバーの鍵ホスト鍵の要約管理者の情報と照合known_hostsへ記録「どのサーバー?」② 利用者を確認自分の鍵秘密鍵で署名サーバーが検証公開鍵と許可を確認「誰が使う?」
代表的な公開鍵認証の場面です。通信用の鍵は鍵合意から導き、公開鍵認証では接続に結び付いたデータへ署名します。
ひよこ ひよこ
SSHの初回接続でyesと聞かれるのはなぜ?
ペンギン先生 ペンギン先生
まだ知っていない接続先のホスト鍵を確認するためだよ。自分のログイン用の鍵とは別。まず、相手が意図したサーバーかを確かめる場面なんだ。
ひよこ ひよこ
画面のSHA256という長い文字は何?
ペンギン先生 ペンギン先生
ホスト鍵のフィンガープリントだよ。鍵を短い要約として比べる助けになる。管理者等から別の信頼できる経路でもらった値と照合するんだ。
ひよこ ひよこ
一度yesと答えれば、次から何も考えなくていい?
ペンギン先生 ペンギン先生
一般的な設定ではknown_hostsへ記録して次回と比べる。鍵が変わったら、再構築など正当な理由か、相手違いや攻撃なのかを確認する。警告を消すためだけに記録を削除しないよ。
ひよこ ひよこ
通信の暗号の鍵も、ホスト鍵そのもの?
ペンギン先生 ペンギン先生
鍵合意から通信用の鍵を導くよ。ホスト鍵は接続先の認証に関わり、通信を暗号化する鍵とは役割が違う。使うアルゴリズムは双方の対応と設定で選ぶんだ。
ひよこ ひよこ
では、自分の公開鍵は何に使う?
ペンギン先生 ペンギン先生
公開鍵認証で、自分が対応する秘密鍵を使えることを署名で示す。RFC 4252ではセッション識別子と認証要求の内容等へ署名する。秘密鍵をサーバーへ送る操作ではないよ。
ひよこ ひよこ
サーバーが毎回乱数の問題を出すの?
ペンギン先生 ペンギン先生
それだけの手順としては説明しないよ。SSHの公開鍵認証では、この接続に結び付いたデータの署名を検証する。サーバーがその鍵でのログインを許していることも必要なんだ。
ひよこ ひよこ
SSHをつなげれば、PCの通信は全部その中を通る?
ペンギン先生 ペンギン先生
通常は接続したセッションだけだよ。-Lは指定した転送、-DはSOCKSへ接続するアプリの転送。アプリ側の設定も必要で、PCのすべての通信が自動で流れるわけではないんだ。
ひよこ ひよこ
新しいOpenSSHでは、量子対策もあるの?
ペンギン先生 ペンギン先生
OpenSSH 10.0ではML-KEMとX25519のハイブリッド鍵合意が既定になり、10.1では耐量子鍵合意を使わない場合の警告が加わった。実際の接続では相手の対応や設定、利用する版も確認しよう。

まずは、2種類の鍵を分ける

サーバーのホスト鍵は接続先が誰か、利用者の公開鍵認証は自分が誰かの確認に使います。どちらも鍵が登場しますが、同じ記録ではありません。

確認よく見る場所
接続先のホスト鍵手元のknown_hosts、管理者からのフィンガープリント
利用者の公開鍵サーバーのauthorized_keys等
利用者の秘密鍵手元の鍵ファイルやエージェント等

自分が管理する公開鍵ファイルがあるなら、OpenSSHの次の読み取り操作で要約を見られます。例のファイル名は手元の公開鍵に置き換えます。

ssh-keygen -l -E sha256 -f demo_key.pub

表示は鍵のビット数、SHA256の値、コメント、種類等です。これは公開鍵の要約を見る操作で、接続先の正当性やログイン成功を確かめたことにはなりません。初回接続の画面では、サーバー管理者等から別の信頼できる経路で取得したホスト鍵の値と比べます。

接続の中で行うこと

  1. TCPで接続し、SSHのバージョンや対応する方式を交渉する。
  2. 鍵合意とホスト鍵を使う認証等で、暗号化した通信を確立する。
  3. パスワードや公開鍵等の方法で利用者を認証する。
  4. 許可されたシェル、コマンド、転送等を使う。

公開鍵認証では、クライアントがセッション識別子と認証要求の内容等へ秘密鍵で署名し、サーバーが署名とその鍵の利用許可を確認します。「サーバーが送った乱数だけへ署名する」という説明では、接続への結び付きが抜けます。

踏み台・転送・鍵の管理

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の仕組みで確認できます。

参考資料