SSH証明書のことは前から知ってたけど、キーから移行する努力はしてなかったんだ。でも、いろんなサーバーやデバイスでSSHキーを手動で管理するのはすごくイライラする。15年の間にたくさんの考えをまとめたと思うけど、切り替えるべきかな？

SSH証明書のもう一つの便利な機能は、ユーザーの公開鍵に署名して、特定のリモートユーザーとしてリモートマシンへのアクセスを限られた時間だけ許可できることだよ。

怖い現実は、多くの人が「鍵」と「証明書」を混同していることだと思う。セキュリティエンジニアと一緒に働いていると、SSH証明書は使わないってことを思い出させないといけないことがあるんだよね。彼らはそれを理解するのにちょっと考えないといけないみたい。

ああ、やばい、10年くらい前に$jobのためにSSH証明書認証局を書いたとき、あなたのブログ記事を参考にしたよ… 書いてくれてありがとう！

TOFUは便利だけど、必須ではないよ。TOFUを使う選択は、SSHで生成されたキーを使う選択とは別のものなんだ。もしTOFUを使いたくないなら、追加のセキュリティのために、対応する公開鍵を安全なチャネル（例えばUSBメモリを使って）でコピーして、コンピュータ同士をペアリングすればいい。証明書を使っても、簡略化や追加のセキュリティは得られないよ。本当のセキュリティを得るには、通信するコンピュータ同士を、やっぱり安全なチャネルで証明書をコピーしてペアリングする必要がある。HTTPSでブラウザに付属している証明書を使うときは、そのインストーラーパッケージが証明書を作成した権威から安全なチャネルでそのコンピュータに届いたと信じることになる。これは、君が管理しているコンピュータ間でTOFUを信頼できるという仮定よりも、はるかに非現実的な仮定だよ。証明書は大きな組織では役立つかもしれないけど、単に安全な通信チャネルを確立する以上の機能が必要な場合、例えば証明書の失効を使いたいときにね。親記事で挙げられている「利点」のリストの半分以上は間違ってる。なぜなら、証明書が正しく実装されていれば、TOFUなしのSSHキーを使うときと証明書を使うときで、完全に同じアクションを実行しなければならないから。著者は「利点」のいくつかを書くことで、証明書を使うときに必要なくなるアクションはユーザーではなく管理者が行うものだと言いたかったのかもしれない。でも、それはSSHにも当てはまる。管理者が証明書をインストールすれば、ユーザーからのアクションは不要になるけど、管理者がSSH公開鍵をインストールすれば、ユーザーからのTOFUも不要になる。証明書を使うには、SSHで生成されたキーを使うのとまったく同じステップが必要なんだ（つまり、証明書を生成して、安全なチャネルでコンピュータ間でコピーして、サーバーと認可されたユーザーをペアリングすること）。でも、証明書は追加の機能を提供するから、追加のステップが必要になることもある。

それに、TOFUのせいでセキュリティ問題が起きたことはないけど、君はどう？ これは、車の事故に遭ったことがないからシートベルトは考慮する価値がないと言ってるようなものだね。設定に関する明らかで文書化された作業を超えて、SSH証明書を使うことに欠点があると思う？

ボックスに接続する前にCA設定を行うためのアクセス手段があるなら、その同じアクセスチャネルを使ってTOFUに頼らずに鍵アクセスを設定できるよ。インストールスクリプトの一部からカスタマイズされたデプロイメントイメージ、仮想化シナリオでのホストへの物理アクセスまで、何でもあり。TOFUは、ボックスがすでに設定されていて、SSHで接続して物をボックスにロードする以外に方法がないときに本当に関係してくる。でも、証明書アプローチを取るつもりなら、同じ話になるよ。

それに、TOFUのせいでセキュリティの問題が起きたことはないけど、君はどう？ TOFUのせいでセキュリティの問題が起きたことがないのは君だけじゃないよ - それ、直したよ。