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のせいでセキュリティの問題が起きたことがないのは君だけじゃないよ - それ、直したよ。

CAを使う代わりに、鍵のPINポリシーを「一度」に設定して、アクティブセッションを保持するエージェント（例：https://github.com/FiloSottile/yubikey-agent/）を使ってみたらどう？エージェントを一日の始まりに起動して、一度PINを入力して、終わりにエージェントを停止する。

TOFUはどう解決するの？

僕の考えでは、ソフトウェアキーを使うのをやめることがもっと重要だから、ホストとユーザーの両方にsk（fido）を使った方がいいと思う。そこからCAが次のステップになるかな。ドキュメントや例のセットアップが驚くほど貧弱で、どの機能のステップ2を見てもそう。つまり、SKキーはユーザーキーとしては理解されてるけど、ホストキーとしての設定は曖昧で、本当に機能するかテストが必要だよ。

Zscalerが友達の職場のWindows 11マシンに導入されたんだけど、ソフトウェアを評価したら、その挙動がまるでマルウェアみたいに悪質だった。知っての通り、TLS/HTTPS接続を監視するために、自分のルート証明書をOSに注入して中間者攻撃を仕掛けるんだよね。さらに、ウェブブラウザの設定をロックして、ZscalerのMITMを回避するためにプロキシサーバーを使えなくしてる。Mozilla Firefoxでこの挙動を見たけど、プロキシオプションが「プロキシなし」に設定されてて、他のオプションは無効化されてグレーアウトしてた。Google Chromeでも同じことしてると思う。ブラウザのプロキシ設定の.iniファイルを変更しようとすると、Zscalerがすぐに上書きしてくる。Zscalerはユーザーを監視するために設定を強制するためにすごく頑張ってるよね。そして、当然だけど、システムトレイのZscaler GUIを開くと、ITパスワードがあればソフトを無効にするオプションが出てくる。でも、もちろん、そんなパスワードは持ってない。まあ、Cybereasonのアンチウイルスソフトよりは少しマシかも。あれはシステムトレイアイコンしかなくて、終了オプションもないし、タスクマネージャーでもローカル管理者でも終了できないし、毎秒何百もの小さなテキストファイルを開くと重くなるから。

僕が働いてるところのCisco Umbrellaについても同じ気持ちだ。最悪なのはプロトコルの破損で、基本的にHTTPを基にした他のプロトコルが頻繁に壊れる。実装してる人たちは全然気づいてないみたい。彼らは「透明だ」と言ってるベンダーの主張を信じてるけど、実際には「検査/トレース専用」モードでもいろんなものが壊れることが多い。Umbrellaが壊したものを挙げると、- Git - RubyGems - go mod - OrbStack - Matrix - Cargo - すべてのJDK - Nix - Pkgsrc - すべてのVM、他にも忘れてるものがあるかも。こういう破損が報告されると、最初の反応は「企業管理されたブラウザでそのドメインにアクセスしたけど、ブロックされてない」っていう無意味で関係のないテスト。多くの場合、破損を完全に診断するのに数時間かかるし、そのツールのせいだと自信を持って指摘するのは難しい。これを買って導入してる人たちが、どれだけのものが壊れるか知らないのか、ただ気にしてないのかはわからないけど、壊れ方はどこにでもあって、誰もそれに備えてないみたい。

SSH証明書はX.509証明書じゃないよ。

1996年からSSHを使ってるけど、そんな風に公的キーを手動で確認してる人を見たことがないよ。もし彼らがあなたのSSHサーバーをMITMできるなら、なんで内部のウェブサイトもMITMできないの？一般的には、TOFUは「はい」と言ってYOLOって感じだね。

なんでSSHを本物のIdPに証明書で接続するんじゃなくて、そうするの？

規制されていない/分散型のSSHキーの使い方（つまり、ssh-copy-idを許可すること）は、ハッカーがネットワーク内で横移動するための夢みたいなものだよね。だから、多くの組織はそれを無効にしてるし、ちゃんとした中央集権的なCAや認証サーバーを整備するためにリソースを投資してないんだ。

キーは個人利用にはすごくいいけど、会社で使うなら中央集権的なキー管理が必要だね（ユーザーごとに1つ以上のキーを発行する）。よくあるのは、全マシンで1つの「開発用SSHキー」を使っちゃう（これは良くない）か、みんながキーを共有したり、マシンに識別できないキーがある状態になること。パスワードは少なくとも「簡単」だから、みんな扱いやすいよね。

ここ数年、私はHSMの後ろに安全に隠されたSSHプライベートキーしか使ってない。攻撃面は超小さいよ。Yubikeyが私には合ってる（他のベンダーでも大丈夫だけど）。私のSSHキーにはパスワードはないけど、SSHでログインする時は、物理的にYubikeyに触れる必要があるんだ（私のYubikeyのうちの1つね）。