OpenSSH証明書認証への本番移行｜ホスト・ユーザCA設計・有効期限ローテーション・ロールバック手順

なぜ今、証明書認証への移行を検討するのか

OpenSSHの公開鍵認証は長く標準的な接続手段として使われてきましたが、ホスト数・ユーザ数が増えるにつれて「鍵の増殖」と「trust管理の煩雑さ」が運用上の問題になりがちです。一般的なつまずきとして、authorized_keysが担当者しか把握していない状態になる、退職者の鍵が残り続ける、ホスト側のknown_hostsが古いままになるといった問題がよく挙げられます。

OpenSSH証明書認証はこれらの課題に対して、CA（認証局）が発行した署名付き証明書を用いることで「誰が・どのホストへ・いつまで」アクセスできるかを一元的に管理する仕組みを提供します。OpenSSH 5.4（2010年）から実装されており、2026年時点で主要ディストリビューションが同梱するOpenSSH 9.x系では機能が安定しています。証明書ベースに移行すると、鍵の有効期限をCAレベルで強制でき、TOFU（Trust On First Use）問題もホストCA署名により解消できます。

ホストCAとユーザCAの設計方針

証明書認証ではCA鍵が2種類存在します。ホストCAはサーバの身元をクライアントに保証するための鍵、ユーザCAはユーザの身元をサーバに保証するための鍵です。この2つを同一の鍵で兼用することは技術的には可能ですが、侵害時の影響範囲を最小化するため、別々に管理することが推奨されます。

CA鍵の保管場所については、規模や要件に応じて選択肢が変わります。小規模環境であればパスフレーズ保護したEd25519鍵をオフライン保管し、証明書発行時のみオンラインにする運用が現実的です。一方、中規模以上ではHashiCorp VaultのSSHシークレットエンジンやStep-CAのようなCA自動化ツールを組み合わせるケースが増えています。Step-CA（Smallstep）は2026年時点でACMEプロトコル経由のSSH証明書自動発行にも対応しており、構成管理ツールと組み合わせた自動ローテーションが実現しやすい選択肢です。

設計時に決めておくべき主なポイントは以下のとおりです。

• ホストCA鍵とユーザCA鍵を分離するか
• 証明書の有効期限（ユーザ証明書は短期、ホスト証明書は比較的長期が一般的）
• プリンシパル（-nオプションで指定するユーザ名・ホスト名）の粒度
• 緊急時に公開鍵認証へ切り戻せるフォールバックをいつ・どのタイミングで閉じるか

本番環境への段階的移行手順

ステップ1：CA鍵の生成と保護

まずCA用の鍵ペアを生成します。鍵の種類はEd25519を推奨します。RSA 4096も利用可能ですが、OpenSSH 9.x以降ではEd25519が性能・安全性ともに優位です。

# ホストCA鍵の生成（CA専用マシンまたはオフライン環境で実行）
ssh-keygen -t ed25519 -f /etc/ssh/ca/host_ca -C "host-ca-2026"

# ユーザCA鍵の生成
ssh-keygen -t ed25519 -f /etc/ssh/ca/user_ca -C "user-ca-2026"

パスフレーズは必ず設定します。CA秘密鍵は証明書発行時のみ読み取り権限を与え、通常時は厳格なパーミッション（600）で保管してください。公開鍵（.pub）は配布用なので別途管理します。

ステップ2：ホスト証明書の発行とサーバ設定

各サーバのホスト鍵にCA署名を付けて証明書を発行します。

# ホスト証明書の発行（有効期限52週間の例）
ssh-keygen -s /etc/ssh/ca/host_ca \
  -I "web01.example.com" \
  -h \
  -n "web01.example.com,web01" \
  -V +52w \
  /etc/ssh/ssh_host_ed25519_key.pub

発行されたssh_host_ed25519_key-cert.pubを対象サーバに配置し、/etc/ssh/sshd_configに以下を追加します。

HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

クライアント側では~/.ssh/known_hostsまたは/etc/ssh/ssh_known_hostsにホストCA公開鍵を登録します。

# known_hostsへのホストCA登録（@cert-authority行）
@cert-authority *.example.com ssh-ed25519 AAAA... host-ca-2026

ステップ3：ユーザ証明書の発行とサーバ側受け入れ設定

ユーザの公開鍵にCA署名を付けてユーザ証明書を発行します。

# ユーザ証明書の発行（有効期限8時間・プリンシパルにログインユーザ名を指定）
ssh-keygen -s /etc/ssh/ca/user_ca \
  -I "alice@example.com" \
  -n "alice,deploy" \
  -V +8h \
  ~/.ssh/id_ed25519.pub

サーバ側のsshd_configにユーザCA公開鍵を信頼する設定を追加します。

TrustedUserCAKeys /etc/ssh/user_ca.pub

この時点では既存の公開鍵認証も残したまま並行稼働させます。sshdを再起動（systemctl reload sshd）し、証明書認証と公開鍵認証の両方が機能することを確認してから次のステップに進みます。

ステップ4：動作検証

接続試験では-vオプションで詳細ログを確認します。証明書認証が使われた場合、ログにcertificateの文字列が出力されます。

ssh -v -i ~/.ssh/id_ed25519 alice@web01.example.com 2>&1 | grep -i cert

サーバ側の/var/log/auth.logまたはjournalctl -u sshdでも認証方式を確認できます。証明書のシリアル番号・有効期限・プリンシパルが想定どおりかssh-keygen -L -f ~/.ssh/id_ed25519-cert.pubで検証しておくと安心です。

有効期限ローテーションの自動化

証明書認証の最大の利点のひとつは有効期限の強制ですが、運用が手動では期限切れによる接続断が発生しやすくなります。ローテーション自動化の手段はいくつかあります。

systemdタイマーによるホスト証明書更新（想定例）：ホスト証明書は有効期限を52週程度に設定し、40週目にsystemdタイマーで更新スクリプトを実行する構成が取れます。スクリプトはCA鍵へのSSH接続（またはAPI呼び出し）で新証明書を取得し、sshdをreloadするだけです。この構成はsystemdが標準化されているDebian/Ubuntu/RHEL系（2026年時点の主流）でそのまま動作します。

Step-CAを使った自動発行：Step-CAのstep sshコマンドはSSH証明書のACME的なライフサイクル管理を提供します。エージェント（step-ssh-agent）がバックグラウンドで証明書の更新を担い、ユーザは意識せずに常に有効な証明書を持てます。短命証明書（8〜24時間）の自動ローテーションを採用しているチームでは、SSH証明書の管理をHashiCorp VaultのSSHエンジンと組み合わせて実装するケースも見られます。

ローテーション設計で注意が必要な点として、CA鍵自体のローテーションがあります。CA鍵を更新した場合、全サーバのTrustedUserCAKeysと全クライアントのknown_hostsも同期して更新する必要があります。Ansibleなどの構成管理ツールと組み合わせると、この伝播を安全に自動化できます。CA鍵ローテーションは頻度を下げ（年1回程度）、ユーザ証明書は短命に保つ設計が実務的です。

ロールバック手順と注意点

証明書認証への完全切り替えは、移行作業中の設定ミスや証明書期限切れで接続不能になるリスクを伴います。そのため、公開鍵認証を即座に有効化できる状態を維持したまま段階的に進めることが重要です。

ロールバックの最も単純な手順は、sshd_configからTrustedUserCAKeysの行をコメントアウトし、systemctl reload sshdを実行することです。ただしこれは「証明書認証を無効化して公開鍵認証のみに戻す」操作であり、接続元から実行できなければコンソールアクセス（クラウドのシリアルコンソール、KVM、AWS Systems Manager Session Managerなど）が必要になります。

切り戻しを安全に行うためのチェックリストとして、以下を事前に確認しておくことを推奨します。

• 帯域外アクセス手段（コンソール、SSM、Bastion経由）が確保されているか
• authorized_keysが削除・上書きされていないか（段階移行中は残す）
• 設定変更前にsshd_configのバックアップを取っているか
• sshd設定の構文チェック（sshd -t）をreload前に実施しているか
• ロールバック手順をRunbookとして共有しているか

一般的なつまずきとして、証明書のプリンシパルとサーバ側のユーザ名が一致しない場合に認証が通らないことがあります。-nオプションで指定したプリンシパルがログイン先のUNIXユーザ名と対応しているか、必ず事前に確認してください。また、AuthorizedPrincipalsFileを使えばプリンシパルとUNIXユーザのマッピングをファイルで細かく制御できます。

2026年現行環境での差分と留意点

OpenSSH 9.x系（Ubuntu 24.04 LTS、RHEL 9.x、Debian 12に同梱）ではいくつかの動作変更があります。OpenSSH 9.0以降、デフォルトでRSA/SHA-1署名が無効化されています。CAがRSA鍵であっても、SHA-256以上での署名（-t rsa-sha2-256またはrsa-sha2-512）が必要です。Ed25519鍵のCA利用は影響を受けません。

OpenSSH 9.8（2024年リリース）ではDSA鍵が完全に廃止されています。古い環境から移行する際にDSA CAが残っている場合は、Ed25519またはRSA-SHA2への更新が必須です。

Fedora 41以降ではOpenSSH 9.9相当が採用されており、FIDO2ハードウェアキーを用いたSSH証明書発行（sk-ed25519タイプのCA鍵）の実用性が高まっています。CA鍵の保護にFIDO2トークンを組み合わせることで、CA秘密鍵のソフトウェア侵害リスクを大きく下げられます。

Hashicorp VaultはOpenSSH証明書のバックエンドとして2026年時点でも広く使われていますが、ライセンス変更（BSL 1.1）の影響でフォークのOpenBaoを選択する組織も増えています。どちらもSSHシークレットエンジンの機能は互換があるため、既存のVault連携手順はそのまま流用できます。

証明書認証への移行はゼロ・トラスト的なアクセス制御の起点としても機能します。有効期限の短い証明書と認証基盤（IdP・SSOとの連携）を組み合わせることで、「証明書が存在する＝直近に認証が行われた」という保証が得られます。鍵の増殖と古いauthorized_keysの整理が課題になっている環境では、段階的な移行であっても早期に着手する価値があります。