SSH秘密鍵を「複製不可能」にする運用と、会社PCでできる現実的な代替

投稿日 2026/05/22

投稿者 rengotaku

14 分で読めます

参考: 複製不可能なSSH鍵運用のススメ

まとめ

ファイルとして置かれた SSH 秘密鍵は、コピー・同期・マルウェアによる窃取のリスクから逃げられない
「複製不可能」とは、秘密鍵をハードウェアの中で生成して 外部にエクスポートできない 状態にし、外に出るのは公開鍵と署名結果だけにする運用
OpenSSH 8.2+ なら FIDO セキュリティキー（YubiKey 等）を 追加ソフトなし で使える。ただしハードウェアの購入と USB 接続許可が必要
会社 PC で物理デバイス追加・サードパーティアプリ導入が現実的でない場合は、ssh-agent / Keychain / 同期除外 / 端末別鍵といった 運用改善で守りを底上げ するのが現実解

ファイル型秘密鍵の何が問題か

慣れた ~/.ssh/id_ed25519 のような鍵は、結局のところ「ただのファイル」だ。これは次のような事故に弱い:

情報窃取マルウェアがホームディレクトリを走査して持ち去る
バックアップやクラウド同期に紛れ込んで複数端末に拡散する
パスフレーズを設定していても、キーロガーや復号後のメモリダンプには無力
「とりあえずコピーで持ち運ぶ」運用が常態化し、どこに何本あるか把握できなくなる

ファイルである以上、「コピーされうる」前提から逃げられない。

「複製不可能」とは何か

スライドが提案している方針は、ざっくり言えば 秘密鍵をファイルとして持たない ことだ。

秘密鍵を専用ハードウェアの中で生成し、そのチップから取り出す API を そもそも提供しない 。ユーザーすら取り出せない。SSH 認証で必要なのは「サーバから渡されたチャレンジに対して秘密鍵で署名する」操作だが、ここを次のように切り替える:

クライアントがチャレンジを受け取る
チャレンジを チップに渡す
チップが内部で署名し、 署名結果だけ返す
クライアントは署名結果をサーバに送る

外に出ていくのは公開鍵（元から公開していい）と署名結果（1 回限りの使い捨て）だけ。秘密鍵そのものはチップから一歩も外に出ない。だから PC がマルウェアに侵されても、秘密鍵は盗めない。タッチや PIN を要求すれば「本人が今その場にいる」も同時に担保できる。

OpenSSH 標準でどこまでできるか

実は OpenSSH 8.2（2020 年）以降、FIDO/U2F 鍵タイプがネイティブにサポートされている。クライアント・サーバとも OpenSSH 8.2+ なら、 追加ソフトなし でハードウェア鍵が使える。

# FIDO セキュリティキーを挿した状態で鍵生成
ssh-keygen -t ed25519-sk     # または ecdsa-sk

# 生成されるファイル
~/.ssh/id_ed25519_sk         # "鍵ハンドル"（秘密鍵本体ではない）
~/.ssh/id_ed25519_sk.pub     # 公開鍵

id_ed25519_sk は秘密鍵そのものではなく、 ハードウェア内の鍵を呼び出すためのハンドル 。ファイルだけ盗まれても、対応する物理デバイスが手元になければ署名できない。

接続時は普通に ssh user@server を叩くと、デバイスが点滅してタッチを要求してくる。タッチすると接続が成立する。タッチしないと反応しない＝ リモートからの自動悪用が不可能 、という性質が効く。

プラットフォーム別の状況

ハードウェアセキュリティキーを買うコストや、社内 USB ポリシーを乗り越える前提があるなら、選択肢はざっくりこう整理できる。

環境	標準的なやり方	追加ソフト
macOS	OpenSSH + FIDO セキュリティキー	不要
macOS	Secure Enclave を SSH 鍵バックエンドにする	必要（Secretive など）
Linux	OpenSSH + FIDO セキュリティキー	不要
Windows	Win32-OpenSSH + FIDO デバイス	不要（ただし設定はやや手間）
Windows	TPM を SSH 鍵バックエンドにする	必要（サードパーティ）
スマートフォン	Termius / Blink などの専用アプリ	必要

「macOS の Secure Enclave を OpenSSH からそのまま使う」標準パスは無いため、Mac で物理デバイス無しに「複製不可能」へ寄せたい場合はサードパーティ製のヘルパーを挟む必要がある。

ハードウェアセキュリティキー（YubiKey 等）の実態

「FIDO セキュリティキー」と聞いて具体像が湧きにくい場合、要は USB に挿す物理デバイス だ。キーホルダーに付けられる小型のハードウェア。端子は USB-A / USB-C / Lightning / NFC など複数ある。

認証時にデバイスの金属部分を指で触る → 認証完了
触らないと反応しない → 「今、本人が物理的にここにいる」を担保
SSH 以外にも GitHub / クラウドサービスの 2FA、PC ログイン、PGP 署名にも使える

「YubiKey」は Yubico 社の商品名（固有名詞）で、同等品として Google Titan / SoloKeys / Nitrokey などがある。実質的には YubiKey がデファクト。

注意点として、 紛失すると詰む ので、通常は 2 本以上買って、片方を金庫等にバックアップ保管する運用が前提になる。サービス側に登録する公開鍵も 2 本分入れておく。

会社 PC の現実

ここまで読むと「では明日から YubiKey で…」となりそうだが、業務 PC 環境では話が変わる。

許可されていない USB デバイスは接続できない（デバイス制御ポリシー）
許可されていないツールはインストールできない（ソフトウェア持ち込み審査）
個人購入のデバイスを業務に持ち込むには資産登録・セキュリティ部門レビューが要る
結局のところ、情シスを巻き込まないと進まない

つまり「FIDO セキュリティキーを挿す」「Secretive を入れる」のどちらも、組織レベルの合意なしでは選択肢に入らない。

会社 PC でできる現実的な底上げ

ハードもサードパーティアプリも追加できない前提でも、ファイル鍵運用のリスクを下げる打ち手はある。

1. パスフレーズを必須にする

裸の秘密鍵ファイルを置かない。最低限の防御線として、流出しただけでは使えない状態にする。

2. `ssh-agent` 経由で扱い、`AddKeysToAgent yes` にする

毎回パスフレーズを叩く運用は形骸化しがちなので、ssh-agent に保持させる。macOS なら ~/.ssh/config に以下を入れて OS のキーチェーンに保護を委ねる:

Host *
    AddKeysToAgent yes
    UseKeychain yes
    IdentityFile ~/.ssh/id_ed25519

これは標準機能だけで実現できるので、会社 PC でも問題になりにくい。

3. クラウド同期・バックアップから `~/.ssh` を除外する

iCloud / Dropbox / OneDrive 等の同期対象から外す。バックアップ製品にも除外設定を入れる。「鍵がいつのまにか複数端末に居る」状況を最初から作らない。

4. 端末ごとに鍵を生成する

複数 PC で同じ鍵を使い回さない。端末ごとに別の鍵を作り、サーバ側にそれぞれの公開鍵を登録する。1 端末が侵害されたとき、他端末の鍵まで巻き込まれない。

5. 鍵の棚卸し

~/.ssh/config の IdentityFile を明示し、使っていない鍵は消す。サーバ側の authorized_keys も定期的に見直して、退役した鍵を残さない。

これらは追加ソフトもデバイスも要らない。~/.ssh/config と運用ルールだけで効く。

組織への提案として通すには

SSH 単独で「YubiKey を全社配布しましょう」は費用対効果の説明が難しい。一方で、GitHub / クラウドコンソール / SSO の 2FA 強化 とセットなら、セキュリティ予算として通しやすい。SSH の複製不可能化は「2FA 統一の副次効果」として後から付いてくる、というロードマップが現実的だ。

個人の作業環境で 100% を狙うのではなく、組織のセキュリティ施策と紐づけて段階的に寄せていく、というのが落としどころになる。

security, infrastructure

まとめ