要約

  • DNSSEC で認証された SSHFP 一致が示すのは、提示された SSH ホスト鍵のアルゴリズムと指紋が、選択された一つの DNS owner name に対応することだ。意図したサービス、ポート、利用者、コマンドまでは示さない。
  • 判断は名前選択、DNSSEC 状態、厳密な指紋比較、SSH の秘密鍵保有証明、ローカル方針から成る。鍵更新では DNS キャッシュと known_hosts の時計も合わせる必要がある。

正しい証明が別の名前に着地する

冒頭では署名もダイジェストも偽造されていない。リゾルバが完全名を選び、DNSSEC 検証が SSHFP RRset を認証し、サーバは対応する秘密鍵で交換データへ署名した。

欠けた問いはその前にある。なぜ db がその名前へ展開されるべきだったのか。

RFC 4255 は非修飾名の危険を明記する。検索パスを注入されると別ホストへ誘導されるため、こうした場合はローカル鍵データベースを先に確認することを勧める。DNSSEC は回答の真正性を守れるが、質問の意図は作れない。

記録には入力名、実効完全名、検索サフィックスまたは CNAME 方針、SSHFP owner、宛先アドレス、ポートを分けて残すべきだ。

レコードの三要素

SSHFP は DNS type 44 である。RDATA は公開鍵アルゴリズム番号、指紋種別、指紋から成る。owner name は外側にある。

照合では受信した公開鍵のアルゴリズム番号が一致し、指定されたダイジェストで公開鍵 blob を計算した値も一致しなければならない。さらに SSH transport は、その鍵による交換データの署名を要求し、サーバが対応秘密鍵を持つことを示す。

ただし保有は独占を意味しない。盗まれた鍵も同じ証明を作る。レコードにはポート、ユーザー、コマンド、IP、役割、有効期間もない。同じ名前の別ポートや踏み台を同じ権限対象にする根拠にはならない。

Secure は検証状態である

RFC 4255 は、信頼された DNS 署名で認証されていない SSHFP を使ってホスト鍵を信頼してはならないとする。検証を外部リゾルバへ委ねるなら、そのリゾルバまでの経路も保護が必要である。

Secure は受け入れた trust anchor の下でデータが検証された状態。Insecure は保護されない委任、Bogus は期待された検証の失敗、Indeterminate は信頼情報不足である。同じ指紋でも状態が違えば権限が違う。

Bogus を可用性のため Insecure に落としてはならない。Secure であっても、認証されるのは問い合わせた owner の RRset であり、DHCP サフィックスや名前正規化の意図ではない。

SHA-256 の不一致は SHA-1 への入口ではない

IANA は RSA、DSA、ECDSA、Ed25519、Ed448 と、SHA-1・SHA-256 の指紋種別を登録している。登録は実装の有効化を保証しない。

RFC 6594 は、SHA-256 対応実装が SHA-1 と SHA-256 の両方を得た場合に SHA-256 を優先するよう求める。SHA-256 が不一致なら、SHA-1 の一致を探して救済せず鍵を拒否しなければならない。

したがって sshfp=match 一語では足りない。owner、鍵アルゴリズム、指紋種別、計算値、試行ごとの結果を残す必要がある。

ローカル方針は消えない

RFC 4255 は SSHFP とローカルファイルの順序を設定可能にする。現行 OpenSSH 文書では VerifyHostKeyDNS の既定値は no。yes なら Secure な一致を暗黙に信頼し、非 Secure は ask と同様に扱う。ask では一致情報を表示しても、新規鍵は StrictHostKeyChecking に従う。

ユーザー・グローバル known_hosts、Host/Match、正規化、許可 CNAME、設定優先順位も結果を変える。期待した設定ファイルではなく、実効値と実行分岐を保存すべきである。

ポートと経路は別の主語

OpenSSH の known_hosts 管理は [hostname]:port を扱える一方、ssh-keygen -r は hostname の SSHFP を出力する。ローカル pin はポートを区別できるが、SSHFP RDATA はできない。

同一名の二つのポートが異なる鍵を示すなら、アプリケーション方針がモデルを決める。踏み台経由では最終ホストの SSHFP が踏み台まで認証するわけでもない。重要な transport leg ごとに鍵判断が要る。

ローテーションには二つの時計がある

RFC 4255 は SSHFP 置換による新鍵配布、強制方針下での削除による失効を想定する。しかし authoritative zone の変更は全キャッシュへ即時反映されない。TTL、RRSIG 期間、known_hosts が別々に残る。

通常更新は新指紋を安全に事前公開し、重要な検証点から観測し、旧新を限定的に重ね、サーバ鍵を切り替え、旧記録を除き、キャッシュ期限後に拒否を試す。緊急時に停止を選ぶなら、明示的なリスク判断として扱う。

サーバ認証の後に利用者認証がある

SSH は transport のサーバ認証と利用者認証を分離する。ホスト鍵の受理は選択したサーバへの通信路を守るが、ユーザー鍵、shell、転送、コマンドを許可しない。

「SSH ホスト確認済み」を秘密配布や特権保守の許可へ直結させる自動化は境界を飛び越える。アカウント、コマンド、変更範囲、冪等性は独立した判断である。

名詞を残す負の試験

同じ短名を二つの検索パスで解決する。Secure、Insecure、Bogus、Indeterminate で同一指紋を試す。SHA-256 だけを不一致にする。ローカル pin、新 SSHFP、二つのポート、踏み台、複製秘密鍵を組み合わせる。最後にホストだけを通し、利用者とコマンドを拒否する。

各結果は owner、状態、anchor、鍵、ポート、経路、方針、次の権限を明記しなければならない。