SSH鍵管理の崩壊パターンと修復手順：散乱した鍵を棚卸しして統制する
SSOプロバイダーのアカウントを停止しても、サーバー上の authorized_keys ファイルに書かれたSSH公開鍵はそのまま残ります。SSOとSSH鍵認証は独立した仕組みであり、どちらか一方を無効化しても、もう一方には影響しません。
退職者のSSOアカウントを停止した翌日も、その人の鍵が生きたままサーバーへの接続を許可し続けている状態は、多くの現場でひっそりと続いています。VisionSpaceが引用する複数の調査によると、60〜90%の組織が有効なSSH鍵の完全な台帳を持っていないとされています。監査が来てから慌てて棚卸しを始めると、対応コストが跳ね上がります。
この記事では、SSH鍵管理が崩壊する5つのパターンを整理したうえで、発見フェーズと修復フェーズを分けた具体的な手順を示します。
authorized_keysが作る「静的な信頼」とその問題
SSH公開鍵認証の仕組みを確認しておきます。ユーザーの公開鍵がサーバーの ~/.ssh/authorized_keys に登録されていれば、対応する秘密鍵を持つクライアントはパスワードなしでそのサーバーに接続できます。
この「認証の判定はサーバーのファイルシステムが持つ」という設計が、SSOとの根本的な違いです。SSOはIdPが認証の可否を制御しますが、SSH公開鍵はあくまでファイルに書かれた文字列です。IdPのアカウントを削除してもファイルは変わりません。
Meta Engineering Blogはこの構造的な問題を次のように指摘しています。「authorized_keysは個別の鍵ペアで信頼を定義するため、スケールしない。署名証明書による認証は、サードパーティインフラに依存しない単一の信頼ポイントを提供する」。サーバー台数・利用者数が増えるほど、静的ファイルによる鍵管理はほころびを見せます。
現場でよく起きるSSH鍵崩壊の5パターン
パターン1: 退職者・外部委託の鍵残存
最も多く、かつ影響が大きいパターンです。人事システムやSSOからアカウントを削除しても、各サーバーの authorized_keys ファイルには手を加えていないケースが後を絶ちません。
MITRE ATT&CKはこの手法を「T1098.004: SSH Authorized Key Manipulation」として脅威モデルに分類しています。攻撃者が永続化のために意図的に挿入する場合もありますが、オフボーディングの手順漏れによって意図せず同じ状態が作られることもあります。
パターン2: 共有鍵・グループ鍵の使い回し
「チーム共有の鍵」を複数人で使い回す運用では、誰が何台のサーバーに接続できるかをファイル単位で追いかけることが実質的に困難です。一人が組織を離れるたびに全員の鍵をローテーションする必要が生じますが、その手順が文書化されていない現場が多くあります。
パターン3: パスフレーズなし鍵
秘密鍵ファイルが盗まれたときの最後の防壁がパスフレーズです。Brandon Checketts氏のベストプラクティスは「パスフレーズは常に設定すること」と明示しています。ラップトップの紛失やノートPCの盗難が発生したとき、パスフレーズなし鍵はそのまま攻撃者の手に渡ります。
パターン4: Key sprawl（鍵とアクセス先のマッピング不明）
Key sprawlとは、誰がどの鍵でどのサーバーにアクセスできるかのマッピングが失われた状態を指します。初期の少人数環境では問題になりにくいですが、サーバー台数・担当者数が増えるにつれて「この鍵は誰のもので、どこにアクセスできるのか」が追えなくなります。削除すべき鍵かどうかの判断すら困難になるため、結果として古い鍵が放置され続けます。
パターン5: 弱いアルゴリズムの混在
過去に生成した鍵が現在の基準を満たしていないケースは珍しくありません。IO Tools のSSH鍵タイプ解説が整理するアルゴリズムの評価は以下のとおりです。
| アルゴリズム | 状態 | 備考 |
|---|---|---|
| DSA | 使用禁止 | OpenSSH 7.0（2015年）以降デフォルト無効。OpenSSH 9.8 でコンパイル時にも無効化済み |
| RSA-1024 | 使用禁止 | 鍵長不足。現行の暗号強度基準を満たさない |
| RSA-2048 | 現在の最小値 | 現時点での最小基準。新規発行はed25519を推奨 |
| Ed25519 | 推奨 | 高速・短い鍵長・強い安全性 |
棚卸しの最初の出力物として、既存環境にDSAやRSA-1024の鍵が残っていないかを確認することが出発点になります。
まず発見フェーズから始める — 削除より前に棚卸し
Linux Security の解説記事は、鍵の整理において重要な警告を述べています。「認識できない鍵を即座に削除しないこと。本番システムは、ドキュメント化されていない自動化処理に依存していることが多い」。
削除を先行させると、CI/CDパイプラインや監視エージェントが突然接続できなくなる可能性があります。発見フェーズと修復フェーズは必ず分けてください。
Step 1: findコマンドで全列挙
まず、サーバー上のすべての authorized_keys ファイルの場所を特定します。
find /home /root /var/lib -name 'authorized_keys*' -type fこのコマンドは /home、/root、/var/lib 配下を再帰的に検索し、authorized_keys ファイルを一覧表示します。Ansibleなどが /etc 以下に配置するケースや /srv を使う環境では、検索範囲を追加してください。
出力をファイルに保存して台帳の起点にします。
find /home /root /var/lib -name 'authorized_keys*' -type f \
> /tmp/authorized_keys_inventory.txtStep 2: フィンガープリント確認
各ファイルに含まれる鍵のフィンガープリントを確認します。フィンガープリントとは、公開鍵を一意に識別するためのハッシュ値で、鍵の比較・突合に使います。
ssh-keygen -lf /home/user/.ssh/authorized_keys出力例:
2048 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx user@hostname (RSA)
256 SHA256:yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy user@hostname (ED25519)複数のサーバーにまたがって棚卸しを行う場合は、このコマンドをループで実行し、フィンガープリントと発見場所を対応させた台帳を作成してください。
Step 3: アルゴリズム種別の判定
フィンガープリントの出力末尾の (RSA) (ED25519) (DSA) 表記でアルゴリズムを判別できます。上記のアルゴリズム比較表に照らし合わせて、DSAまたはRSA-1024の鍵をリストアップします。
台帳として最低限持っておきたい列は次のとおりです。
| 列 | 内容 |
|---|---|
| ファイルパス | authorized_keys が存在する場所 |
| フィンガープリント | ssh-keygen -lf の出力 |
| アルゴリズム | RSA / Ed25519 / DSA 等 |
| 鍵長 | RSAの場合は2048以上かを確認 |
| 所有者（確認済みの場合） | 人事台帳またはGitHub公開鍵との照合結果 |
| 最終確認日 | ローテーション管理のための基準日 |
修復と鍵ローテーションの実行設計
削除実行前の確認
台帳が揃ったら、削除対象の鍵がシステムの自動処理に使われていないかを確認します。チェックポイントは以下のとおりです。
- デプロイスクリプト・CI/CDパイプライン内の鍵参照
- 監視エージェント・バックアップツールが使うサービスアカウントの鍵
- cronジョブやAnsibleプレイブックの接続先設定
削除は変更管理ウィンドウ（システム変更を実施する事前合意された時間帯）内で実施し、事前にバックアップを取ります。
cp ~/.ssh/authorized_keys ~/.ssh/authorized_keys.bak.$(date +%Y%m%d)Ed25519への移行
新規に生成する鍵はEd25519を使います。Brandon Checketts氏のベストプラクティスに基づく生成コマンドは以下のとおりです。
ssh-keygen -t ed25519 -f ~/.ssh/your-key-filename -C 'your-key-comment'-C オプションのコメントには鍵の用途・所有者・作成日を含めると台帳管理が楽になります（例: [email protected]）。
OpenSSH 10.3（2026年4月2日リリース）では、Ed25519鍵のPKCS8形式での書き出しサポートと、libcrypto経由でのEd25519署名スキームサポートが加わっています。ツールチェーンがPKCS8形式を要求する場合は、このバージョン以降で対応できます。その他の変更点はリリースノートで詳細を確認してください。
パスフレーズは必ず設定してください。ssh-agent を使えば、セッション中のパスフレーズ入力を省略しながらも鍵ファイルを保護できます。
鍵ローテーションの運用設計
Brandon Checketts氏は「約2年ごとに新しいSSH鍵を作成すること」を推奨しています。ローテーションを運用として回すには、次の要素を設計に含めてください。
命名規則の統一: 鍵ファイル名に作成日・用途・所有者を含めることで、台帳なしでも鍵の素性を追えます。
例: id_ed25519_alice_deploy_20260702
移行の順序:
- 新しい鍵ペアを生成する
- 新しい公開鍵を
authorized_keysに追記する - 新しい鍵での接続を確認する
- 古い公開鍵を
authorized_keysから削除する - 古い秘密鍵ファイルを安全に削除する
古い鍵を先に削除してから新しい鍵を追加するのではなく、必ず「追記→確認→削除」の順で行います。
authorized_keysを卒業する選択肢 — SSH CAと管理ツールの比較
静的ファイルで台帳管理・ローテーションを運用し続けることには限界があります。サーバー台数・利用者数が増えるほど管理コストが上がり、人的ミスが発生しやすくなります。ここでは、authorized_keysへの依存を減らすための選択肢を整理します。
SSH CAによる証明書認証
SSH CA（Certificate Authority）とは、ユーザーの公開鍵にCAが署名することで、個別の鍵登録なしにアクセスを制御する仕組みです。
Smallstep の解説が示す設定例では、サーバーに TrustedUserCAKeys /etc/ssh/ssh_user_key.pub を指定するだけで、CAが署名した証明書を持つユーザーを一括して受け入れられます。証明書にはTTL（有効期限）を設定でき、同ページの例では4時間のみ有効な証明書が発行されています。TTLが切れれば証明書は自動的に無効になります。
Meta Engineering Blogが指摘するとおり、この方式では ~/.ssh/authorized_keys への個別登録が不要になり、CAの証明書を無効化するだけで対象ユーザーのアクセスをまとめて遮断できます。
サーバーの初期ハードニング手順についてはVPSの初期セキュリティ設定チェックリストも参照してください。
Teleport
Teleport（テレポート）は、SSH・Kubernetes・データベースなどへのアクセスを証明書ベースで一元管理するオープンソースのアクセスプロキシです。
公式ドキュメントによると、Teleportは証明書の自動発行・TTLの設定・CAのローテーションをサポートしています。ユーザーは tsh コマンドでSSO経由で認証し、TTL付きの短命な証明書を受け取ります。証明書が失効すれば再認証が必要になるため、退職者や外部委託の鍵が残存するリスクを構造的に排除できます。
料金は環境・規模によって異なります。最新の料金は goteleport.com/pricing/ で確認してください。
Tailscale SSH
Tailscale SSH（テールスケールSSH）は、WireGuardベースのメッシュVPNであるTailscaleのネットワーク上でSSH接続を管理する機能です。
公式Knowledge Baseによると、Tailscale SSHはWireGuardキーを使い、セッション終了後に自動的に失効します。重要な点として、/etc/ssh/sshd_config や ~/.ssh/authorized_keys ファイルは変更されません。既存のSSH設定やauthorized_keysには手を加えずに、Tailnetへの参加を条件としたアクセス制御を追加できます。
対応OS・機能制限については、公式ドキュメントで最新情報を確認してください。
状況別の選択基準
| 状況 | 検討候補 |
|---|---|
| 数台のサーバー・少人数チーム | SSH CA（smallstep等）+ 手動台帳 |
| すでにTailscaleを使っている | Tailscale SSH |
| 複数サービス・多様なプロトコルを統合管理したい | Teleport |
| 大規模エンタープライズ・厳格なコンプライアンス要件あり | Teleport Enterprise |
実行時の注意点と落とし穴
OpenSSH 10.3 の変更点: OpenSSH 10.3（2026年4月2日リリース）ではEd25519鍵のlibcrypto経由の署名スキームサポートとPKCS8形式の書き出しサポートが加わっています。バグ修正を含む全変更点はリリースノートで確認してください。証明書認証を運用している環境では、バージョンアップ前に動作確認を行うことを推奨します。
Teleport導入時のコスト: Teleportはフルスタックのアクセスプロキシであり、導入・運用コストが伴います。既存のSSH設定・ファイアウォールルール・CI/CD連携の見直しが必要になる場合があります。PoC（概念実証）環境で動作を確認してから本番導入を検討してください。
Tailscale SSHの環境依存: Tailscale SSHの機能は、対応OS・Tailscaleのバージョン・Tailnetの設定によって動作が異なります。公式ドキュメントで対応状況を事前に確認してください。
統計数値の扱いについて: 「60〜90%の組織がSSH鍵の台帳を持たない」「特権アクセスを含む侵害の平均損害が$4.5Mを超える」という数値は、VisionSpaceが複数の調査を引用してまとめたものです。自組織のリスク評価に一次調査として使うのではなく、課題の優先度を判断する参考値として扱ってください。
なお、VisionSpaceが引用するデータによると、エンタープライズグレードのSSH鍵管理システムのコストはエンドポイントあたり年間10〜50ドル（2026年7月時点の参考値）とされています。規模・要件によって大きく変わるため、各ベンダーの最新見積もりを取ることを推奨します。
SSH鍵の棚卸し・整理・移行は、手順そのものより「何から手をつけるか」の優先順位付けが難しい作業です。既存サーバーの台帳化から始めたい場合も、SSH CAやTeleportへの移行を検討したい場合も、現状の整理から相談できます。