OpenSSHの証明書認証で鍵配布を集中管理する｜CA構築から証明書失効まで一通りの手順

公開鍵配布の限界と証明書認証が解決する問題

サーバ台数が増えてくると、従来の公開鍵認証は運用の重荷になります。担当者が変わるたびに authorized_keys を全台に配布し直す作業、退職者の鍵を確実に抜いたか確認するための突合作業——こうした手作業は見落としやすく、ミスが即セキュリティホールに直結します。

OpenSSHの証明書認証は、この問題を「信頼の委譲」で解消します。仕組みは単純で、組織内にCA（認証局）鍵を一本用意し、そのCAが署名した証明書を持つユーザーだけをサーバが信頼するというものです。各サーバに配布するのはCAの公開鍵1ファイルだけで、個別の authorized_keys 管理は不要になります。証明書には有効期限を設定できるため、失効作業も大幅に簡略化できます。

本記事では、CAの構築から証明書の発行・配布・失効処理まで、実際の運用シナリオに沿って一通りの手順を確認します。対象環境はOpenSSH 8.2以降（Ubuntu 22.04 / AlmaLinux 9など2026年現在の主流ディストリビューション）です。

CA鍵の生成とサーバへの配置

CA鍵はユーザー証明書に署名するための鍵ペアです。秘密鍵が漏洩すると組織全体の信頼が崩壊するため、CA専用のセキュアな管理ホスト（インターネット非公開・ストレージ暗号化済み）で生成するのが現場での標準的な扱いです。

# CA専用ホストで実行
ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key -C "user-ca-2024"

生成される ca_user_key（秘密鍵）と ca_user_key.pub（公開鍵）のうち、公開鍵だけを各SSHサーバへ配布します。秘密鍵はCA管理ホスト外に出さないことが大前提です。

各SSHサーバの /etc/ssh/sshd_config に以下の1行を追加し、CAの公開鍵を信頼するよう設定します。

TrustedUserCAKeys /etc/ssh/ca_user_key.pub

設定を反映するにはsshdの再起動が必要です。systemdベースのディストリビューションでは systemctl reload sshd でシグナルを送るだけで設定を再読み込みできます（接続中のセッションを切断しません）。

sudo systemctl reload sshd

ユーザー証明書の発行と配布

ユーザーは自分の公開鍵をCA管理担当者に提出します。担当者はCA秘密鍵でその公開鍵に署名し、証明書ファイルを返却します。

署名コマンドの基本形

ssh-keygen -s /etc/ssh/ca_user_key \
  -I "alice@example.com" \
  -n alice,deploy \
  -V +52w \
  alice_ed25519.pub

各オプションの意味を整理します。

• -s：署名に使うCA秘密鍵のパス
• -I：証明書のID文字列。ログに残るため、誰の証明書かを一意に識別できる値にします
• -n：ログイン可能なユーザー名（プリンシパル）のカンマ区切りリスト
• -V：有効期間。+52w は52週間（約1年）。+1d（1日）や +8h（8時間）のような短期証明書も実運用で使われます

署名が成功すると alice_ed25519-cert.pub が生成されます。このファイルをユーザーの ~/.ssh/ に置くだけで、次回接続時から証明書認証が有効になります。

証明書の内容確認

発行した証明書の内容は -L オプションで確認できます。有効期限やプリンシパルの設定ミスをここで検出します。

ssh-keygen -L -f alice_ed25519-cert.pub

出力の Valid 行に from/to の日時、Principals 行に許可ユーザー名が表示されます。本番配布前にこの確認を必ず行うことを、運用手順書に明記しておくと後の事故を防ぎやすくなります。

接続テストと認証フローの検証

証明書認証が正しく機能しているかをユーザー側・サーバ側の両面から確認します。

ユーザー側の確認

-v オプション付きで接続すると認証の試行順序がわかります。

ssh -v -i ~/.ssh/alice_ed25519 alice@target-server

出力の中に Offering public key: ... certificate ID "alice@example.com" という行と、それに続く Server accepts key の行が見えれば証明書認証が成立しています。

サーバ側のログ確認

systemdベースの環境では journalctl でsshdのログをリアルタイム確認できます。

sudo journalctl -u sshd -f

証明書認証が通ると Accepted publickey for alice ... ID alice@example.com (serial 1) CA ... のような行が記録されます。シリアル番号がログに残るため、のちに問題が起きた際の追跡が容易になります。なお、シリアル番号は -z オプションで署名時に付番しておくと管理台帳と突合しやすくなります。

証明書の失効——KRL（Key Revocation List）の運用

有効期限内に証明書を失効させる必要が生じた場合（退職・紛失・セキュリティインシデント）、OpenSSHはKRLという失効リスト機構を用意しています。

KRLの作成と更新

特定の証明書を失効させるには対象の証明書ファイルを使います。

# 初回作成（または既存KRLへ追記）
ssh-keygen -k -f /etc/ssh/revoked_keys \
  -s /etc/ssh/ca_user_key.pub \
  alice_ed25519-cert.pub

証明書ファイルが手元にない場合は、シリアル番号でも失効を指定できます。

ssh-keygen -k -f /etc/ssh/revoked_keys \
  -s /etc/ssh/ca_user_key.pub \
  -z 5

この -z 5 はシリアル番号5番の証明書を失効対象に追加する指定です。シリアル番号を管理台帳に記録しておく理由はここにあります。

サーバへのKRL配布

生成した revoked_keys ファイルを各サーバに配置し、sshd_config に参照先を追記します。

RevokedKeys /etc/ssh/revoked_keys

設定追記後は systemctl reload sshd で反映します。KRLファイルの配布はAnsibleやFabricなどの構成管理ツールで自動化するのが実際の現場では一般的です。sshdはKRLファイルを接続のたびに読み込むため、ファイルを上書き配置するだけで即座に失効が有効になります（sshd再起動不要）。

失効が機能しているかの確認は、失効済み証明書で接続を試みて Permission denied が返ることで行います。成功ではなく拒否されることが正解であるため、テスト手順に「失効後の拒否確認」を明示的に組み込んでおくとよいでしょう。

2026年の現行環境における注意点と差分

OpenSSH 9.x系が主流となった2026年の環境では、いくつかの点で以前の情報と差異があります。

RSA-SHA2への移行完了

OpenSSH 8.8以降、ssh-rsa（SHA-1）はデフォルト無効です。CA鍵をRSAで作成する場合は rsa-sha2-256 または rsa-sha2-512 が署名アルゴリズムとして使われます。新規に構築するCA鍵はEd25519が事実上の推奨であり、Ubuntu 22.04・AlmaLinux 9標準のOpenSSHでは -t ed25519 を指定すれば問題なく機能します。

FIDO2/パスキー対応の証明書

OpenSSH 8.2以降、sk-ed25519（FIDO2ハードウェアキー）ベースの鍵ペアにも証明書署名が可能です。フィッシング耐性の高い物理トークンとCA証明書管理を組み合わせる運用が、特権アカウント向けに広がっています。ただし、受け入れ側のSSHサーバも8.2以降である必要があります。

切り戻し手順の明確化

証明書認証への移行後に問題が発生した場合の切り戻しは、TrustedUserCAKeys 行をコメントアウトして systemctl reload sshd するだけで従来の authorized_keys 認証に戻せます。移行初期は必ず既存の公開鍵認証と並行稼働させ、証明書認証が全ユーザーで安定して動作することを確認してから authorized_keys を削除する順序が安全です。並行稼働期間中は、sshdのログで各ユーザーが証明書認証（Accepted publickey ... ID）を使っているかを確認しながら進めます。

また、KRLファイルが破損したり不正なフォーマットになった場合、sshdが証明書認証を全拒否するケースがあります。KRLの更新はCA管理ホストで行い、差し替え前に ssh-keygen -Q -f revoked_keys -s ca_user_key.pub test_cert.pub で内容の整合性を確認する習慣を付けておくと、配布ミスによるロックアウトを防ぎやすくなります。