ssh で yes を押す」方式は、TOFU（Trust On First Use）で、完全な防御ではないSSH は、リモートのサーバーに安全にログインするための定番ツールです。
ただし、新しいサーバーに初めて接続するときだけは、話が少しややこしい。
なぜなら、その時点では「相手が本当にそのサーバーか」を確認するための情報が、手元にまだないからです。
SSH はここで、
“The authenticity of host … can't be established. Are you sure you want to continue connecting (yes/no/[fingerprint])?”
のように聞いてきます。
多くの人は yes を押してしまいます。
これは TOFU (Trust On First Use)、つまり「最初は信じる、次から覚えて照合する」という考え方です。
これ、実用上は便利です。正直、毎回厳密に確認していたら面倒すぎる。
でも問題は、最初の1回だけは攻撃者が横取りできることです。
もしネットワークを支配されたら、攻撃者は本物のサーバーのふりをして、あなたを別の機械へ誘導できるかもしれません。
著者はここを強く指摘しています。
「yes を押すだけでは、初回接続を守れていない」と。これはかなり重要なポイントだと思います。
記事の核心はシンプルです。
つまり、最初から本命の鍵を渡すのではなく、**“使い捨ての信用切符”で入場して、本物の本人確認書類をもらう**イメージです。
この発想はかなりきれいです。地味ですが、筋がいい。
しかもこの記事の手法では、単に鍵を手で見て known_hosts に書くのではなく、OpenSSH の key rotation をうまく使って、長期鍵が自然に known_hosts に入るようにしている点が面白いです。
これにより、HashKnownHosts のような設定にもちゃんと対応しやすくなります。こういう「雑に見えて、実は細部が丁寧」な設計は好きです。
ここはかなり大事です。
「じゃあ、最初から本物の SSH host key を cloud-init で配ればいいのでは？」
と思うかもしれません。実際、そうすれば初回接続の認証自体はできます。
でも、著者はそれを危険だと説明しています。なぜなら、cloud-init の user-data に秘密鍵（private key）が入ってしまうからです。
秘密鍵は“秘密”であることが命です。
ところが cloud-init の user-data は、状況によっては漏れやすい。
たとえば記事では、以下のような経路が挙げられています。
つまり、「最初の認証のために秘密鍵を埋め込む」と、認証のために置いたはずのものが、むしろ新たな弱点になるわけです。
これはかなりイヤな話ですが、現実的でもあります。
著者はかなり丁寧に threat model（脅威モデル、どういう攻撃まで想定するか）を書いています。
ここが誠実で好感が持てます。
この方法は、次のような相手に強いです。
でも、鍵の扱いがうまく設計されているので、攻撃者が“価値ある鍵素材”を持ち去るタイミングがない。
ここが肝です。
ちょっと面白いのがここです。
攻撃者が管理者端末を完全に支配していても、VMに実際に接続しない限り、VM の長期 host key を盗めないケースを想定しています。
要するに、「管理者端末がやられたら全部終わり」ではなく、少なくとも鍵の所在を限定するわけです。
鍵を管理者端末に置かない設計は、やっぱり強い。
逆に、VMやクラウド事業者が悪い/怪しい場合でも、管理者端末におかしなデータを食わせにくくする工夫もしています。
特に、単にサーバーの出力をそのまま ~/.ssh/known_hosts に書くのではなく、OpenSSH が鍵として認識できるものだけを使う流れにしているのがポイントです。
これは地味ですが、かなり大事です。
「信じて書き込む」ではなく、OpenSSH の仕組みに沿って安全に取り込む。こういう堅実さ、好きです。
著者は少し横道として、「実際、MITM 攻撃はどこまで成功するのか」も考察しています。
ここはかなり現場感があります。
ざっくり言うと、攻撃者が成功しやすいのはこんな場合です。
逆に、もしあなたが
なら、攻撃者はかなり苦しくなる、としています。
ここでの教訓はシンプルで、
SSH は安全そうに見えて、設定次第で攻撃面がかなり広がるということです。
個人的には、特に agent forwarding は便利さと危険さが同居していて、いつも少し怖い機能だと思っています。
このアイデアの面白さは、**“初回接続問題”を真正面から解きにいっている**点です。
SSH の初回接続は、長年「まあ、yes 押して運用している」ことが多かった領域です。
でもそれって、実はセキュリティ的にはかなりモヤっとしている。
著者はそこを、プロバイダ独自機能に頼らず、cloud-init だけで解くというのがいい。
しかも、
という、かなり実用寄りの美しさがあります。
「派手な新技術」ではないけれど、現場で効く工夫という感じです。
こういうのは派手さはないですが、実際にはとても価値があると思います。
この記事は、SSH の初回接続でよくある
「とりあえず yes」問題 に対して、かなり筋の良い解決策を提示しています。
ポイントは、
という流れです。
個人的には、こういう「誰もがなんとなく妥協していた部分」を、ちゃんと設計し直す記事はとても好きです。
派手ではないけれど、セキュリティの現場ではこういう一手がすごく効く。そう思います。