authorized_keysという悩みの種
チームに50台のサーバーと10人のスタッフがいるとしましょう。新しいメンバーが加われてたびに、公開鍵をもらって各サーバーにSSHでログインし、~/.ssh/authorized_keysファイルに追記しなければなりません。このプロセスには少なくとも30〜40分かかり、非常にミスが発生しやすい作業です。
本当の問題は、誰かが退職したときに発生します。昨年のフィンテックシステムのセキュリティ監査で、2年前に退職した開発者の鍵がまだ本番サーバーに残っているのを見て衝撃を受けたことがあります。たった1台のサーバーでも見落としがあれば、システムに致命的な脆弱性が生じます。SSH認証局(SSH CA)こそが、この分散管理に終止符を打つ解決策です。
SSH CAの仕組み
サーバーに膨大な公開鍵のリストを覚えさせる代わりに、「身分証明書の発行局」モデルに移行します。サーバーには、「私が発行した証明書を持っていれば、アクセスを許可していい」と伝えるだけで済みます。
このメカニズムは、以下の3つのシンプルなステップで動作します:
- サーバー側: CAマシンからの「電子署名」のみを信頼するように設定します。
- クライアント側(ユーザー): 自分の公開鍵をCAマシンに送って署名を受けます。CAは証明書(Certificate)を返します。
- 接続時: ユーザーが証明書を提示します。サーバーが署名を検証し、一致すればすぐにアクセスを許可します。
SSH CAの素晴らしい点は、有効期限(Expiration)を設定できることです。例えば、勤務時間の8時間だけ有効な証明書を発行することができます。その時間が過ぎれば、証明書は自動的に無効化されます。たとえ開発者のPCが盗まれたとしても、攻撃者が翌日にその鍵を使ってアクセスすることはできません。
実際の導入手順
CA用のマシン(オフラインマシンまたは隔離されたサーバーを推奨)と、ターゲットサーバー(Target Server)を準備する必要があります。
ステップ1:認証局の「印鑑」を作成する
CAマシンでルート鍵ペアを作成します。これは最も重要な資産であるため、非常に強力なパスフレーズで保護してください。
# 保存ディレクトリの作成
mkdir ~/ssh-ca && cd ~/ssh-ca
# セキュリティ最適化のためed25519アルゴリズムを使用
ssh-keygen -t ed25519 -f ssh_ca -C "Company SSH CA"
このコマンドにより、ssh_ca(秘密鍵 – 厳重管理)とssh_ca.pub(公開鍵 – 配布用)が生成されます。
ステップ2:サーバーがCAを信頼するように設定する
ssh_ca.pubファイルをすべてのターゲットサーバーに転送する必要があります。例えば、/etc/ssh/ssh_ca.pubに配置します。
# サーバーにファイルを転送
scp ssh_ca.pub [email protected]:/etc/ssh/
ターゲットサーバーのSSH設定ファイルを開きます:
sudo nano /etc/ssh/sshd_config
ファイルの末尾に以下の設定を追加します:
TrustedUserCAKeys /etc/ssh/ssh_ca.pub
最後に、変更を適用するためにサービスを再起動します:
sudo systemctl restart ssh
ステップ3:従業員の証明書に署名する
Anさん(ユーザー名: an.nguyen)がアクセスを必要とする場合、彼女から公開鍵を送ってもらい、署名を行います:
# an.nguyenという識別子で1日間有効な鍵に署名する
ssh-keygen -s ssh_ca -I "an.nguyen-access" -n an.nguyen -V +1d id_ed25519.pub
重要なパラメータ:
-s ssh_ca: 署名にCA鍵を使用します。-n an.nguyen: ログインを許可する特定のユーザー名を指定します。-V +1d: 証明書の有効期限です。+4h(4時間)のように、より厳密に設定することも可能です。
結果としてid_ed25519-cert.pubファイルが生成されます。このファイルをAnさんに送り返します。
ステップ4:接続確認
Anさんは自分のPCの~/.ssh/ディレクトリに証明書ファイルを置くだけです。SSHコマンドを実行すると、すべてが自動的に行われます。
ssh [email protected]
Anさんは無事にサーバーにログインできました。もうどのサーバーのauthorized_keysファイルも触る必要はありません。
応用:”Unknown Host” 警告の解消
新しいサーバーにSSH接続するたびに、フィンガープリントを信頼するかどうかの確認メッセージが表示されます。SSH CAは、ホスト証明書(Host Certificate)を使用してこれを解決できます。
- サーバー自体の公開鍵に、
-hフラグを付けてCA鍵で署名します。 - サーバーの
sshd_configファイルでHostCertificateを設定します。 - 自分のPCの
known_hostsファイルに@cert-authority * [ssh_ca.pubの内容]という行を追加します。
これで、システム内のすべてのサーバーが個人のPCから自動的に信頼されるようになります。煩わしい警告メッセージはもう表示されません。
運用における実務経験
SSH CAの導入は非常に快適ですが、以下の3点に注意してください:
- 安全第一: もしCAの秘密鍵が漏洩すると、攻撃者はすべてのサーバーへのアクセス権を得てしまいます。鍵をYubiKeyや専用のHSMデバイスに保存することを検討してください。
- 自動化: ずっと手動で署名し続けるのは避けましょう。HashiCorp Vaultを使用してAPI経由で証明書を発行することをお勧めします。そうすれば、開発者はVaultにログインするだけで、その日使う証明書を取得できます。
- 追跡:
/var/log/auth.logのログを確認してください。すべてのログインセッションにはKey ID(-Iパラメータ)が記録されるため、誰がいつサーバーに入ったかを正確に把握できます。
SSH CAへの移行は、あらゆるDevOpsチームにとってプロフェッショナルな一歩です。作業が楽になるだけでなく、システムのセキュリティを新たなレベルへと引き上げることができます。

