Summary

  • RFC 4251 は、ホスト名と公開ホスト鍵の対応を手元に保存し、以後の接続で照合する方式を記述している。
  • OpenSSH はその記憶を known_hosts に置く。新しい鍵を尋ねて登録し、既知の相手が別の鍵を出せば拒否できる。認証済みサーバーから次の鍵を先に教わる方法もある。

SSH の鍵交換でサーバーはホスト鍵を提示する。クライアントに必要なのは、その鍵が目的の名前を持つサーバーのものだという根拠だ。2006 年 1 月の RFC 4251は、名前と鍵をローカルの帳簿に結びつける方法と、信頼する認証局に証明してもらう方法を並べる。前者なら中央の受付を待つ必要はない。最初の記帳を誰が確かめるかという仕事は残る。

RFC は、初回に受け取った鍵を保存し、次の接続から比較する運用を説明する。これは機械に記憶を与える方法だ。ただし初回を横取りされたら、攻撃者の鍵が「前から知っている相手」として記録されかねない。RFC が別の経路による指紋の照合を挙げる理由はそこにある。正しい鍵を記録できれば、同じホスト名を名乗る別の鍵は次回から目立つ。

OpenSSH の帳簿は ~/.ssh/known_hosts だ。OpenBSD の ssh(1) マニュアルは保存先と、既知のホスト鍵が変わったときの大きな警告を説明する。警告は犯人を名指ししない。サーバーの再構築や予定された鍵交換でも変化は起きるし、偽物も同じ兆候を作る。だが、前回と今回が食い違うという事実を、黙って通してはくれない。

OpenBSD の ssh_config(5)を見ると、初対面の扱いを選べる。StrictHostKeyChecking=ask は新しい相手について確認を求め、既知の相手の鍵変更は拒む。accept-new は初登場なら自動登録し、変更にはやはり立ち止まる。yes では新しい鍵を事前に手で登録する。入口の速さは変わっても、記録済みの顔を勝手に描き直させない点が肝心だ。

鍵の交代は段取りよく行える。UpdateHostKeys なら、すでに認証を終えたサーバーが追加のホスト鍵を知らせられる。古い鍵で本人確認ができるうちに新しい鍵を帳簿に載せ、後で古い方を退役させる。顔を知る人が次の担当者を紹介する形だ。

ssh-keyscan は鍵を集めて known_hosts 用の形式で出力する。しかしマニュアルは、採集だけでは鍵の持ち主を確かめられないと明言する。通信経路に割り込む人も鍵を提示できるからだ。ノートを埋める速さより、最初に何を書いたか。その後ずっと役に立つのは、そこを忘れない仕組みである。