最初のSSH接続における中間者攻撃（MITM）を停止する手法
本記事は、新規VMやクラウドプロバイダーにおける最初のSSH接続での中間者攻撃（MITM）を防止するスクリプトを紹介している。
この技術は、広くサポートされているcloud-init機能を利用し、一時的なSSHホストキーを注入することで、信頼性を確保している。
この一時的な信頼期間を利用し、長期的な正規のSSHホストキーを確立してから一時キーを破棄する。
これにより、プロバイダーに依存しない形で、最初の接続のセキュリティを飛躍的に向上させることができる。
クラウド環境で新規に立ち上げた仮想マシン（VM）への最初のSSH接続は、セキュリティ上の大きな盲点となりがちです。特に、中間者攻撃（MITM）のリスクが指摘されています。今回、特定のクラウドプロバイダーに依存せず、標準機能であるcloud-initを利用してこの初期接続の安全性を高める手法が提案されました。
初期接続のMITM攻撃対策
従来のSSH接続では、ホストの認証が確立できない際（Trust On First Use: TOFU）に「yes」と応答することが一般的です。しかし、この行為は、攻撃者が通信経路を傍受するプロキシに誘導したり、VM自体を乗っ取ったりするリスクを伴います。提案された手法は、この最初の接続時に一時的なSSHホストキーを注入することで、攻撃からVMを保護することを目指しています。
一時キーと長期キーの利用戦略
この技術の核心は、cloud-initを通じて一時的なSSHホストの秘密鍵をVMに注入することにあります。この一時キーを利用して最初の接続を認証した後、VMはすぐに「本物の（長期の）」SSHホストキーを生成・取得します。これにより、一時キーの利用期間を最小限に抑え、長期的なセキュリティを確保しています。
セキュリティモデルとリスク分析
この手法は、ネットワーク上の攻撃者によるMITM攻撃に対してVMの完全性を保護します。ただし、cloud-initのユーザーデータに長期秘密鍵が一時的に含まれるため、SSRFなどの脆弱性を突かれた場合、攻撃者がその鍵情報にアクセスできる可能性も指摘されています。そのため、SSHプロトコル自体の安全性を前提としています。
まとめ
この技術は、特定のクラウド環境に依存しない汎用的な初期セキュリティ対策として注目されています。ただし、攻撃者がどのように振る舞うかによって成功率が左右されるため、運用上の注意点も理解しておく必要があります。
原文の冒頭を表示（英語・3段落のみ）
This little script stops attacks on the first SSH connection to a new VM, even on providers (like Hetzner Cloud) that don't offer a proprietary solution; we only need cloud-init, which is widely supported.
Summary (for experts; read on for a longer explanation): inject a temporary SSH host (private) key via cloud-init, and trust that temporary SSH host key just long enough to generate and retrieve the "real" (long-term) SSH host keys.
The script is a simple but hardened implementation of this technique; the comments in the script discuss implementation choices.
※ 著作権に配慮し、引用は冒頭3段落までです。続きは元記事をご覧ください。