LinuxのOpenSSH証明書認証入門｜鍵認証より安全なCA署名ベースのSSH認証を実践導入する方法

SSH接続の管理に追われていませんか。サーバーが10台を超えたあたりから、どの鍵をどのサーバーに登録したか把握しきれなくなり、退職者の公開鍵が authorized_keys に残ったまま…という状況は、決して珍しくありません。

この記事では、そうした鍵管理の混乱を根本から解消できるOpenSSH証明書認証を解説します。CA（認証局）の構築から、ユーザー証明書・ホスト証明書の発行、有効期限管理まで、現場で使える手順をステップごとに紹介します。

OpenSSH証明書認証とは？

OpenSSH証明書認証とは、独自のCA（Certificate Authority: 認証局）が署名した証明書を使ってSSH接続を認証する仕組みです。

通常の公開鍵認証では、各サーバーの ~/.ssh/authorized_keys に個別の公開鍵を列挙します。サーバーが100台あれば100か所の authorized_keys を管理しなければなりません。

証明書認証では、「CAの公開鍵を信頼する」という1行の設定だけで済みます。あとはCAが署名した証明書を持つユーザーは自動的に信頼されます。

なお、ここで扱うOpenSSH証明書はTLS/HTTPSで使われるX.509証明書（PEM形式）とは別物です。OpenSSH独自のフォーマットであり、PKI（公開鍵基盤）の知識がなくても導入できます。

鍵認証の限界と証明書認証のメリット

公開鍵認証はSSHのデファクトスタンダードとして長年使われてきた優れた方式ですが、大規模環境では次のような課題が出てきます。

・鍵の配布・削除が煩雑: 新しい鍵を全サーバーに追加・削除するたびに手作業が発生する
・退職者の鍵削除漏れ: 担当者が変わった際に古い鍵が残り続けるリスクがある
・鍵の棚卸しが困難: どの鍵がどのユーザーのものか追跡できなくなる
・ホスト検証がおろそかになりがち: 初回接続時の「known_hosts警告」をそのまま通過する運用が定着しやすい

証明書認証を導入すると、これらの問題が次のように変わります。

・鍵配布が不要: CAの公開鍵を一度配布するだけで、以降はCAが署名する証明書を発行するだけでよい
・有効期限を強制できる: 証明書に有効期限を設定でき、失効すれば自動的にアクセス不可になる
・ホストなりすましを防止: ホスト証明書により接続先サーバーの正当性をCAが保証できる
・アクセス制御の一元管理: CAを停止・失効すれば全ユーザーのアクセスを即時に遮断できる

OpenSSH証明書認証の仕組み

証明書認証の全体像を整理しておきましょう。登場するのは3つの役割です。

・CA（認証局）: SSH用のCA鍵ペアを管理する専用マシン。ユーザーの公開鍵に署名して証明書を発行する
・SSHサーバー: 接続を受け付けるサーバー。CAの公開鍵を信頼リストに登録しておく
・SSHクライアント（ユーザーのPC）: CAに署名された証明書を持ち、接続時に提示する

認証の流れは次のとおりです。

# ① ユーザーが自分の公開鍵をCA管理者に送る
# ② CAがその公開鍵に署名してユーザー証明書を発行する
# ③ ユーザーがSSH接続時に証明書を提示する
# ④ SSHサーバーがCA公開鍵で証明書の署名を検証する
# ⑤ 検証成功 → ログイン許可

この流れにより、SSHサーバーは個別の公開鍵を知らなくても、「CAを信頼する」という設定だけでユーザーを認証できます。

CA（認証局）の構築手順

では実際に設定を進めましょう。CAとして使うマシンは、インターネットから隔離された安全な環境が理想です。本番運用ではCA用のサーバーを専用で用意することをおすすめします。

1. CA鍵ペアの生成

CAとして使うサーバーで、ユーザー用CAとホスト用CAの2種類の鍵ペアを作成します。

# ユーザー認証用のCA鍵ペアを生成
ssh-keygen -t ed25519 -f /etc/ssh/ca_user_key -C "user-ca"

# ホスト認証用のCA鍵ペアを生成
ssh-keygen -t ed25519 -f /etc/ssh/ca_host_key -C "host-ca"

# 秘密鍵のパーミッションを制限する（rootのみ読み取り可）
chmod 600 /etc/ssh/ca_user_key /etc/ssh/ca_host_key
chmod 644 /etc/ssh/ca_user_key.pub /etc/ssh/ca_host_key.pub

重要: CA秘密鍵（ca_user_key・ca_host_key）は厳重に保管してください。これが漏洩すると攻撃者が任意の証明書を発行できるようになります。パスフレーズの設定も必ず行いましょう。

2. CA公開鍵を全SSHサーバーに配布

CA公開鍵を接続先の各SSHサーバーに配布して信頼させます。

# CA公開鍵を各サーバーにコピー（例: ansibleやscpで全台配布）
scp /etc/ssh/ca_user_key.pub admin@server01:/etc/ssh/ca_user_key.pub

# 各SSHサーバーの /etc/ssh/sshd_config に追記する設定
TrustedUserCAKeys /etc/ssh/ca_user_key.pub

# sshd_configの文法チェック
sshd -t

# 設定をリロード（接続中のセッションを切らずに反映）
systemctl reload sshd

既存の authorized_keys による認証はそのまま残しておけます。段階的に移行したい場合は、TrustedUserCAKeys の追加だけで始められます。

sshd_configの詳細なセキュリティ設定については、Linuxのsshd_config設定完全ガイドもあわせて参照してください。

ユーザー証明書の発行と設定

1. ユーザーの公開鍵をCA側で署名する

ユーザーは自分の公開鍵（~/.ssh/id_ed25519.pub）をCA管理者に送ります。CA側では以下のコマンドで署名します。

# ユーザー証明書の発行
# -s: CA秘密鍵を指定
# -I: 証明書の識別子（ユーザー名や説明。ログに記録される）
# -n: ログイン可能なUnixユーザー名（カンマ区切りで複数指定可）
# -V: 有効期限（+52w = 52週間、+1d = 1日、+8h = 8時間など）
# -z: シリアル番号（KRLで失効させる際に使う）
ssh-keygen -s /etc/ssh/ca_user_key   -I "alice@example.com"   -n alice   -V +52w   -z 001   alice_id_ed25519.pub

# 発行された証明書ファイルを確認
# alice_id_ed25519-cert.pub というファイルが生成される
ssh-keygen -L -f alice_id_ed25519-cert.pub

ssh-keygen -L で証明書の内容（有効期限・許可ユーザー名・シリアル番号など）を確認できます。発行前にしっかり内容を確認する習慣をつけましょう。

2. ユーザー側での証明書の配置と接続確認

発行された証明書ファイルをユーザーのPCに戻します。

# ユーザーのPC上での配置
# 秘密鍵: ~/.ssh/id_ed25519
# 公開鍵: ~/.ssh/id_ed25519.pub
# 証明書: ~/.ssh/id_ed25519-cert.pub  ← ここに配置（自動検出される）

# パーミッション設定
chmod 600 ~/.ssh/id_ed25519-cert.pub

# SSH接続（OpenSSHが証明書を自動的に検出して使用する）
ssh alice@server.example.com

# 接続時に証明書が使われているか確認
ssh -v alice@server.example.com 2>&1 | grep -i cert

秘密鍵と同じファイル名に -cert.pub を付けた形で配置するだけで、OpenSSHが自動的に証明書を使って認証します。~/.ssh/config への追加設定は不要です。

ホスト証明書の発行と設定

ユーザー証明書でユーザーを認証するのと同様に、ホスト証明書を使うとSSHサーバー自身の正当性も証明できます。接続時の「known_hosts確認」を自動化でき、中間者攻撃のリスクを大幅に下げられます。

1. サーバーのホスト鍵に署名する

# 対象サーバーの /etc/ssh/ssh_host_ed25519_key.pub を取得してCA側で署名
# -h: ホスト証明書として発行するオプション（必須）
# -n: ホスト名またはIPアドレス（クライアントが接続に使う値）
ssh-keygen -s /etc/ssh/ca_host_key   -I "server01.example.com"   -h   -n "server01.example.com,192.168.1.10"   -V +52w   /etc/ssh/ssh_host_ed25519_key.pub

# 生成されたホスト証明書: /etc/ssh/ssh_host_ed25519_key-cert.pub
# サーバーに戻してパーミッションを設定
chmod 644 /etc/ssh/ssh_host_ed25519_key-cert.pub

2. サーバーにホスト証明書を設定する

# /etc/ssh/sshd_config に追記
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

# 反映
systemctl reload sshd

3. クライアント側でホストCAを信頼させる

# ユーザーのPCの ~/.ssh/known_hosts に以下を追記
# @cert-authority の後にホスト名パターンを指定し、CA公開鍵を貼り付ける
@cert-authority *.example.com ssh-ed25519 AAAA...（ca_host_key.pubの内容）

# この設定により、*.example.com に接続した際に
# ホスト証明書をCA公開鍵で検証するようになる
# known_hostsに個別サーバーのIPを追加しなくて済む

このひと手間で、初回接続時の「Are you sure you want to continue connecting?」確認が不要になります。

証明書の有効期限管理と失効

OpenSSH証明書認証の強みは有効期限を強制できる点です。ただし、X.509証明書のようなCRL（証明書失効リスト）の仕組みがないため、失効管理には工夫が必要です。

・KRL（Key Revocation List）の活用: OpenSSH独自の失効リスト機能。ssh-keygen -k で作成し、sshd_config の RevokedKeys に指定する
・短い有効期限を設定する: -V +1d（1日）や -V +8h（8時間）など短期間の証明書にして、失効の代わりに再発行を要求する運用
・証明書の発行を自動化する: HashiCorp VaultのSSH Secrets Engineなどのツールと組み合わせると、短期証明書でも運用負荷を下げられる

KRLの基本的な使い方は次のとおりです。

# KRLの作成（失効させたい証明書ファイルを指定）
ssh-keygen -k -f /etc/ssh/revoked_keys   -s /etc/ssh/ca_user_key   alice_id_ed25519-cert.pub

# sshd_config にKRLファイルを指定（全台に配布が必要）
RevokedKeys /etc/ssh/revoked_keys

# 設定反映後、aliceの証明書はどのサーバーでも拒否される
systemctl reload sshd

KRLは 全SSHサーバーに配布しないと効果がない点に注意してください。AnsibleなどのIaCツールでの配布自動化をセットで設計しましょう。

中小企業でも今日からできること

「CA構築って難しそう」と感じた方も、次の手順で段階的に導入できます。

・まず1台のテスト環境から始める: テスト用サーバー1台でCA検証環境を作り、動作確認してから本番展開する
・既存の公開鍵認証と併用する: TrustedUserCAKeys を追加しても authorized_keys による認証は引き続き機能する。並行稼働で段階的に移行できる
・Bastionホスト（踏み台サーバー）から先行導入する: 全社員が通過するBastionホストに先行導入することで、効果を最大化しながらリスクを最小化できる
・ユーザー証明書の有効期限を長めに設定する: 運用負荷を考えて最初は +52w（1年）から始め、慣れたら短くしていく

Bastionホストの設計については、Bastionホスト（踏み台サーバー）のセキュリティ設計も参考になります。

また、ブルートフォース攻撃対策としてfail2banと組み合わせることでさらに堅牢な構成になります。

Linuxサーバーの一般的なSSHセキュリティ設定については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

よくある誤解と注意点

・「証明書認証だけで完結する」は誤り: CAサーバー自体のアクセス制限・秘密鍵の物理的な保護・CA操作のログ記録など、CA運用のセキュリティ設計が別途必要
・「X.509証明書（PEM形式）と同じもの」ではない: OpenSSH証明書はTLS/HTTPSで使うX.509証明書とは異なる独自フォーマット。混同しないよう注意
・「有効期限切れ証明書は自動で再発行されない」: 期限が切れると接続できなくなる。証明書の更新フローをあらかじめ設計しておく
・「known_hostsを削除してよいわけではない」: ホスト証明書を導入しても、known_hostsの完全削除は不要。@cert-authority エントリを追加する形で共存させる
・「SSH二要素認証（OTP）との排他関係ではない」: 証明書認証は鍵認証の一種であり、PAM＋OTPによる二要素認証と組み合わせることも可能

本記事のまとめ

OpenSSH証明書認証は、初期設定に少し手間がかかりますが、サーバー台数が増えるほど効果を発揮します。まずは1台のテスト環境でCA構築とユーザー証明書発行を試してみてください。「こんなにシンプルに管理できるのか」と実感できるはずです。