Scribble at 2026-11-11 09:02:13 Last modified: 2026-11-11 09:04:04

添付画像

I deleted all my SSH keys

上の記事の著者は、従来のディスク上に保存されたSSH秘密鍵を完全に廃止して、ハードウェアに保護されたSSH鍵のみを使う運用へ移行した体験をまとめている。なぜ移行したのかというと、まず著者はパスフレーズ付きの通常のSSH鍵でも多くの場合は十分安全だと認めている。秘密鍵は暗号化され、ssh-agent を使えば利便性も高いからだ。しかし、それでも、秘密鍵をディスクに平文で置かず、鍵の持ち出しや窃取をさらに困難にして、ハードウェアを持っていなければ認証できないようにするという目的から、ハードウェア保護方式へ移行したという。そら、パソコンのデータにそのままアクセスされただけで秘密鍵が奪われたら終わりだもんなぁ。

そこで、著者の選択としては、以下の三つがあったらしい。

1. YubiKey

2. TPM(Trusted Platform Module)

3. Apple Secure Enclave

そして、著者は環境に応じてこれらを使い分けることで、すべての環境から通常のオンディスクSSH秘密鍵を排除できたと述べている。

一方で、ハードウェア依存には新たなリスクがある。YubiKeyを紛失するとか、TPM付きマシンが故障するとか、あるいはMacを買い替えるときだ。そういう場合には鍵が使えなくなる可能性があるため、複数の認証鍵を事前に登録して冗長化しておくことが重要だと締めくくっている。

僕は、いまのところ /Secure というフォルダに入れてある秘密鍵とか KeePass のデータベース・ファイルとかを Google Drive などに同期して保管しているくらいであり、さほど強い保護でもない。そして、上の記事で紹介されているような方法で更に強く保護するかと言われても、ちょっとそれは躊躇するな。もちろん、導入した場合のリスクが気になるからだ。特に、特殊なハードウェアを使うとお金がかかるという問題もある。

たぶん、平文のまま秘密鍵を保存せずに強く保護する簡単な方法は、当サイトでもご紹介していた「秘密分散」だろう。ツールの readme くらいしか文書を公開していなかったから、いまは取り下げているけれど、もちろん情報の保護として否定するつもりはない。秘密鍵を5つくらいのフレーズに分散させて、それぞれ異なるクラウド・ストレージや NAS などに保管し、少なくとも分散したフレーズの一つはファイルに記述して保存するのではなく、自分で記憶しておくことが望ましい。ただし、だからといって保護の強度が上がるわけではない。秘密分散の逆操作は一定の閾値を越えたら、自分で記憶しているフレーズがなくても復号化できてしまうからだ。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る