SSH 認証局
Vault で保護された SSH 証明書の発行 — 静的なホスト鍵や authorized_keys ファイルを置き換える、短命なホスト証明書とユーザー証明書。
SSH 認証局とは
SSH 認証局（SSH CA） は Vault で保護された署名鍵であり、静的で長期間有効な鍵ファイルに依存する代わりに、短命で暗号学的に署名された SSH 証明書を発行します。CA の秘密鍵が Vault の外に出ることはありません — すべての証明書は Vault バックエンド内でその場で署名され、これは DuoKey の他の鍵管理ワークフローが署名素材をアプリケーション層の手の届かないところに保つのと同じ方式です。
署名鍵が Vault の外に出ることはありません。短命な証明書が、かつて sshd が信頼していた静的ファイルを置き換えます。
SSH CA は、SSH で最も古くからある二つの信頼の問題を解決します。
静的なホスト鍵
通常、クライアントは初回接続時にサーバーのホスト鍵を信頼し（trust-on-first-use）、known_hosts に黙って記憶します。ホスト証明書を使うと、サーバーはクライアントがすでに信頼している CA によって署名された証明書を提示できるため、盲目的に受け入れるものも、古くなったまま記憶され続けるものもなくなります。
静的な authorized_keys ファイル
通常、各サーバーはログインを許可する公開鍵の一覧を自身で保持しており、それを手作業で配布・整理する必要があります。ユーザー証明書を使うと、sshd は指定されたユーザー名の組に対して CA が署名した任意の鍵を信頼できるため、サーバーごとに保守すべきファイルがなくなります。
SSH 認証局は Cockpit のナビゲーションにおける独立した項目であり、Apps カタログのエントリーではありません。独自の機能フラグと権限サブツリーの背後にあり、エディションが許可するまでデフォルトでは無効です。
証明書の種類
SSH CA は 2 種類の証明書を発行できます。どちらも設計上短命であり、証明書の有効期間は発行元 CA に設定された最大値で制限されます。
| 種類 | 証明する対象 | 置き換えるもの | プリンシパルフィールドの意味 |
|---|---|---|---|
| ホスト | 接続してくるクライアントに提示される、サーバーのホスト鍵 | `known_hosts` を通じて信頼される静的なホスト鍵 | 証明書が有効なホスト名／IP アドレス |
| ユーザー | サーバーに提示される、人またはサービスの鍵 | `authorized_keys` 内の静的なエントリー | 証明書が認証されるサーバー側のユーザー名 |
SSH CA の署名鍵には EC P-256、EC P-384、RSA 2048、RSA 4096 のいずれかを使用できます — CA の作成時に一度だけ選択します。CA の公開鍵は標準的な OpenSSH 公開鍵行として公開されるため、sshd_config の TrustedUserCAKeys（ユーザー証明書用）や、クライアントの known_hosts の @cert-authority 行（ホスト証明書用）にそのまま貼り付けられます。
SSH CA の作成と証明書の発行
CA を作成する
Cockpit の SSH 認証局セクションから CA を作成します。名前と任意の説明を付け、署名鍵を保持する Vault バックエンドを選び、鍵アルゴリズムを選択し、発行する証明書が要求できる最大の証明書有効期間（TTL）を設定します。Cockpit は選択された Vault 内に署名鍵を生成し、CA の公開鍵行とフィンガープリントを返します — 秘密鍵そのものが公開されることはありません。
ホスト証明書を発行する
サーバーの OpenSSH 公開鍵、有効とすべきホスト名／IP アドレス（そのプリンシパル）、および任意の TTL（CA の最大値で制限されます）を送信します。Cockpit は署名済みの証明書行を返すので、sshd がクライアントに提示できるようサーバーのホスト鍵と一緒にインストールします。
ユーザー証明書を発行する
ユーザーまたはサービスの OpenSSH 公開鍵と、認証対象となるサーバー側のユーザー名（そのプリンシパル）を送信します。返された証明書行は authorized_keys のエントリーの代わりに使用します — 対象の sshd は CA を信頼するだけでよく、個々の鍵を管理する必要はありません。
必要に応じて失効させる
鍵が侵害された場合や、発行済みの証明書をこれ以上信頼すべきでない場合は、任意の理由を添えて Cockpit から失効させます。失効した証明書は、失効チェックを行う以降の接続から除外されます（後述）。
以下の五つのステップは、発行から、証明書を信頼する（または後に拒否する）接続に至るまでに実際に起こることです。
Vault の境界を越えるのは署名だけです — 証明書自体は通常の OpenSSH 公開鍵行として流通します。
明示的な TTL を指定せずに発行された証明書は、発行元 CA に設定された最大 TTL の期間有効です — その最大値自体も、設定せずに CA を作成した場合は1 時間がデフォルトです。長期間有効な証明書ではなく、短い TTL（と短い CA 最大値）と再発行を優先してください — 自動的に期限切れになる証明書には、失効のための仕組みが不要です。
すべての証明書は key id（未設定の場合は最初のプリンシパルがデフォルトとなるラベル）と、一つ以上のプリンシパル — ホスト証明書ではホスト名／IP、ユーザー証明書ではユーザー名 — を持ちます。プリンシパルは最低一つ必要です。
CA のライフサイクル: ローテーションと無効化
| ステータス | 意味 |
|---|---|
| アクティブ | この CA は新しい証明書を発行できます。 |
| ローテーション済み | この CA は新しく生成された CA 鍵に置き換えられました。これ以上証明書を発行することはできません。 |
| 無効化済み | この CA は手動で運用から外されました。これ以上証明書を発行することはできません。 |
CA をローテーションすると新しい署名鍵が生成され、古い CA は Rotated としてマークされます。古い鍵の下ですでに発行された証明書は、個別には有効なままです — 各証明書には署名に使われた CA 公開鍵が埋め込まれているため、検証は CA の現在のステータスに依存しません。ただし、sshd の信頼 CA 設定（known_hosts の @cert-authority 行、TrustedUserCAKeys）を新しい公開鍵に更新しなければ、ローテーション後の CA から新たに提示される証明書は、新規接続で信頼されません。
CA を無効化すると、置き換えを生成することなく、それ以上の証明書発行を停止できます — 新しい CA をすぐにローテーションで導入せずに CA を引退させたい場合に使用します。
失効と revoked-keys ファイル
証明書を失効させると、任意の理由とともに Revoked としてマークされますが、失効が効果を持つのは sshd にそれをチェックするよう指示した場合だけです。Cockpit は revoked-keys ファイル — 特定の CA について、現在失効しているすべての証明書の対象鍵を 1 行 1 公開鍵で列挙した平文の一覧 — を公開しており、sshd_config の RevokedKeys ディレクティブから直接参照できます。
# Point sshd at the CA's public key for certificate-based trust,
# and at the revoked-keys file for revocation checking.
TrustedUserCAKeys /etc/ssh/ca.pub
RevokedKeys /etc/ssh/revoked_keys
revoked-keys ファイルは、バイナリの OpenSSH KRL 形式ではなく、平文のテキスト一覧（失効した証明書ごとに 1 行の OpenSSH 公開鍵行、ソート済み・重複排除済み）です。失効のたびに再取得し、sshd が読み込むコピーを更新してください。
ライブ署名のための PKCS#11 エンロールメント
Cockpit コンソールからオンデマンドで証明書を発行するだけでなく、SSH CA をエンロールすることで、オンプレミスの sshd や ssh-agent との連携から証明書署名をライブで要求できます。これは DuoKey の他の PKCS#11 連携と同じパターンです（Oracle TDE の pkcs11.toml を参照）。
CA をライブ署名用にエンロールする
CA の詳細ページから、PKCS#11 アクセス用にエンロールします。Cockpit は、この CA 自身のライブ署名エンドポイントを指す pkcs11.toml 形式の設定ファイルと、一度だけ表示されるベアラーアクセストークンを生成します。
設定をインストールする
生成された設定を、PKCS#11 対応の SSH ツールと一緒に保存します。オンプレミスのクライアントは、すべての署名リクエストを Authorization ヘッダー内のベアラートークンで認証します — トークンがエンドポイント URL に埋め込まれることはありません。
ライブで署名する
エンロール後、クライアントは PKCS#11 ブリッジを通じて CA の公開鍵を参照し、証明書データに対する署名を要求できます。オペレーターがコンソールから証明書を一つずつ手作業で発行する必要はありません。
すべてのライブ署名リクエストを認証するのはベアラートークンであり、URL 内の CA id ではありません。
ライブ PKCS#11 ブリッジが公開するのは、SSH CA に必要な操作 — CA 鍵の参照と署名 — だけであり、暗号化、復号、wrap、unwrap は公開されません。CA の鍵素材は常に Vault 内に留まります。
ライブ PKCS#11 署名は、基本となる SSH 認証局機能の上に独自のエンタイトルメントでゲートされており、エンロールには専用の権限が必要です。エンタイトルメントはエンロール時だけでなく、すべての署名呼び出しで再チェックされます — したがって、エディションにそれが含まれなくなると、すでにエンロール済みのクライアントであってもライブ署名は即座に停止します。
エンロール時に返されるベアラートークンは認証情報であり、URL 内の CA id ではありません。生成された設定ファイルはアクセス権限を制限して保存し、万一漏洩した場合は再エンロール（新しいトークンが発行されます）してください。
権限とエンタイトルメント
SSH 認証局には、他のあらゆる Cockpit モジュールとは分離された独自の権限サブツリーに加え、モジュール全体をゲートする機能フラグと、ライブ PKCS#11 ブリッジを個別にゲートする二つ目のフラグがあります。
| 領域 | 統制する範囲 |
|---|---|
| CA 管理 | SSH CA の作成、参照、ローテーション、無効化、削除 |
| 証明書 | 証明書の参照、ホスト証明書の発行、ユーザー証明書の発行、証明書の失効 |
| PKCS#11 エンロールメント | CA をライブ署名用にエンロールする — モジュールの他の部分とは別にゲートされます |