SSHの仕組み — 安全なリモート接続はどう実現されている？

いい質問だね。SSHが登場する前はTelnetというプロトコルが使われていたんだけど、Telnetは通信内容が全部平文（暗号化なし）で流れるんだ。パスワードもコマンドも丸見え。SSHは通信を丸ごと暗号化するから、途中で盗み見されても中身が分からないんだよ。

SSHの接続はまずTCPで3ウェイハンドシェイクした後、お互いのSSHプロトコルバージョンを交換するところから始まるよ。そのあとDiffie-Hellman鍵交換という仕組みで、お互いだけが知っている共通の秘密鍵を作り出すんだ。面白いのは、この秘密鍵自体はネットワーク上を一度も流れないこと。数学的なトリックで、公開情報だけをやり取りしても同じ鍵を導き出せるんだよ。

Diffie-Hellmanは本当によくできた仕組みだよね。でも、ここで一つ問題がある。通信相手が本物のサーバーかどうか、どうやって確認する？ 初めてサーバーに接続すると「Are you sure you want to continue connecting?」って聞かれるでしょ。あれはサーバーのホスト鍵のフィンガープリントを表示して、本物かどうか確認させているんだ。

本来はサーバー管理者からフィンガープリントを事前にもらって照合すべきなんだ。yesと答えると、そのホスト鍵が ~/.ssh/known_hosts に保存される。次回以降はこのファイルと照合して、もし鍵が変わっていたら「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」という警告が出る。これは中間者攻撃の可能性を示すから、絶対に無視しちゃダメだよ。

パスワード認証は文字通りパスワードを送る方式。SSHで暗号化されてるから盗聴はされにくいけど、ブルートフォース攻撃には弱い。一方、公開鍵認証はid_rsaやid_ed25519といった鍵ペアを使う方式で、秘密鍵は手元に、公開鍵はサーバーの ~/.ssh/authorized_keys に登録しておくんだ。

チャレンジ・レスポンス方式だよ。サーバーがランダムなデータ（チャレンジ）を送って、クライアントが秘密鍵でそれに署名して返す。サーバーは登録済みの公開鍵で署名を検証する。秘密鍵を持っている人しか正しい署名は作れないから、これで本人確認ができるんだ。秘密鍵自体はネットワークに一切出ないのがポイントだね。

そう、SSHの強力な機能だね。-L オプションのローカルフォワーディングは、手元のポートからSSH越しにリモート先のサービスに接続できる。例えば ssh -L 3306:db-server:3306 bastion で、手元のlocalhost:3306がリモートのDBに繋がる。-R のリモートフォワーディングは逆方向で、サーバー側のポートを手元に転送する。-D はSOCKSプロキシを立てて、すべての通信をSSH経由にできるよ。

ssh-agentは秘密鍵をメモリに保持してくれるプログラムだよ。パスフレーズ付きの秘密鍵を毎回入力するのは面倒でしょ？ssh-addで一度登録すれば、以降はパスフレーズなしで認証できる。さらにエージェントフォワーディング（ssh -A）を使うと、踏み台サーバー経由で別のサーバーに接続するとき、手元のエージェントの鍵をそのまま使える。ただし、踏み台サーバーの管理者が悪意を持っていると鍵を悪用される危険があるから、信頼できるサーバーでのみ使うべきだね。

SSH認証局（SSH CA）という仕組みがあるよ。CAの秘密鍵でユーザーの公開鍵に署名して証明書を発行するんだ。サーバー側はCAの公開鍵だけ信頼すればいいから、authorized_keysの管理が不要になる。有効期限も設定できるし、大規模環境では必須の仕組みだね。あとProxyJump（ssh -J）を使えば、ssh -J bastion target-server で踏み台経由の接続がワンコマンドでできるよ。

2024年に大きな事件があったよ。xz/liblzmaというデータ圧縮ライブラリに、sshdを標的としたバックドアが仕込まれたんだ。2年以上かけて信頼を築いたメンテナーが悪意あるコードを紛れ込ませていたという、サプライチェーン攻撃の典型例。PostgreSQLの開発者がsshd接続の遅延に気づいて発覚したんだけど、もし気づかれなかったらSSH接続時に任意コードが実行される恐れがあった。SSHのプロトコル自体は堅牢でも、実装やその依存関係が攻撃対象になりうるという教訓だね。