Vault SSH エンジン実践ガイド: OTP と CA 署名の使い分け

Vault の SSH エンジンは、ワンタイムパスワード（OTP）方式と、Vault を SSH CA として使う証明書署名方式の2つを提供します。両者はネットワーク要件、導入コスト、失効戦略が異なります。

本稿では、公式ドキュメントに基づく安定した動作を前提に、設計判断材料、最小構成手順、試験で問われやすい観点をまとめます。

Vault SSH エンジンの全体像と試験観点

Vault の SSH エンジンは、サーバへの SSH アクセス制御を中央集約するための仕組みです。実装としては、ユーザが一度だけ使えるパスワードを払い出す OTP モードと、Vault を SSH 認証局（CA）として公開鍵に短命の証明書を付与する CA 署名モードがあります。

Associate/Ops レベルでは、どのモードをどの条件で選ぶべきか、サーバ側の設定要件、TTL と失効の考え方、監査ログの活用、ローテーション運用が問われやすいです。OTP はサーバ側に PAM 連携のヘルパ導入が必要で、認証時に Vault と通信します。CA 署名はサーバに CA 公開鍵を信頼させる設定のみで、認証時に Vault との通信は不要です。

• OTP は一回限り・短時間有効のパスワード。サーバは Vault にアウトバウンドで到達できる必要がある
• CA 署名は短命の SSH 証明書を発行。サーバは TrustedUserCAKeys の設定で Vault の CA 公開鍵を信頼
• どちらも Vault の Role でユーザやCIDR、TTL等の制約を集中管理できる

SSH OTP モードのしくみと要件

OTP モードでは、ユーザは Vault から一度だけ使えるパスワードを取得し、それを SSH のパスワード認証として利用します。サーバ側は PAM 連携の vault-ssh-helper 等を導入し、受け取ったパスワード（OTP）を Vault API に照会して正当性を検証します。OTP は1回のみ有効で、短い TTL が設定されます。

Vault 側では SSH エンジンを有効化し、key_type=otp の Role を作成します。Role には default_user、allowed_users、cidr_list、port、ttl、max_ttl などの制約を設定できます。接続元や宛先ユーザを中央で制御できるため、使い捨ての踏み台用途や段階的導入に適します。

• 要件: サーバから Vault へのアウトバウンド通信（認証時）
• サーバ: PAM に vault-ssh-helper を組み込み、Vault のアドレスと CA を設定
• クライアント: vault CLI で OTP を取得し、ssh パスワードとして使用
• 特性: 一回限り、短 TTL、サーバごとにヘルパ導入が必要

SSH CA 署名モードのしくみと要件

CA 署名モードでは、Vault が SSH のユーザ用 CA として署名鍵を保持し、ユーザの公開鍵に有効期限やプリンシパル等を含む証明書を付与します。サーバは sshd_config の TrustedUserCAKeys で Vault の CA 公開鍵を信頼し、接続時に提示される鍵＋証明書の検証のみで認証を完結できます。認証時にサーバが Vault へ通信する必要はありません。

Vault 側の Role（key_type=ca）では、allowed_users や default_user、ttl/max_ttl、allowed_extensions、default_extensions、allowed_critical_options などを定義して署名ポリシーを制御します。失効は短い TTL とキーのローテーションで担保するのが一般的です。集中署名により大規模環境での配布・回収コストを下げられます。

• 要件: サーバに Vault の CA 公開鍵を配布して信頼設定
• サーバ: OpenSSH の TrustedUserCAKeys を設定し再読込
• クライアント: 自身の公開鍵を Vault に提出して短命証明書を取得し、鍵と併用して接続
• 特性: 短 TTL、認証時に Vault との通信不要、大規模運用に向く

OTP と CA の接続フロー

OTP と CA の比較と選定指針

段階導入や踏み台用途など、サーバ側への軽微な設定変更から始めたい場合は OTP が有効です。一方で、サーバ台数やユーザ数が多い環境では CA 署名が運用負荷を大きく下げます。特にオフライン環境やゼロトラストの観点では、認証時に Vault への到達性を必要としない CA 署名が有利です。

試験では、ネットワーク到達性、サーバ側要件、失効戦略（TTL とローテーション）、Role での制御項目の違いを軸に選定根拠を答えられるかが問われます。

• 初期導入容易性を重視: OTP
• スケールと認証時のオフライン性を重視: CA 署名
• 厳密な失効管理が必要: CA は短 TTL とキー・ローテーションで担保、OTP は一回限りで即時失効の性質

最小構成レシピ（OTP と CA）

以下は学習・検証向けの最小例です。実運用では TLS 検証、Policy の最小権限化、監査ログを必ず有効化してください。サーバ側の sshd 設定変更はメンテナンスウィンドウで行い、必ず別セッションを残して疎通確認します。

同一の Vault インスタンスで OTP と CA を併用できます。役割ごとに Role を分離し、CIDR、ユーザ、TTL を厳格化します。

• Vault 側: SSH エンジン有効化、Role 作成（OTP/CA）
• サーバ側: OTP は PAM 連携導入、CA は TrustedUserCAKeys 設定
• クライアント側: OTP は password、CA は 鍵＋証明書 で接続

手順例: Vault 側設定、サーバ設定、接続

# 1) Vault 側: SSH エンジンを有効化
vault secrets enable ssh

# 2) OTP モード: Role を作成（例）
vault write ssh/roles/otp-admin \
  key_type=otp \
  default_user=ubuntu \
  allowed_users=ubuntu \
  cidr_list=10.0.0.0/24 \
  port=22 \
  ttl=5m

# 3) サーバ側（OTP）: vault-ssh-helper の設定例
# /etc/vault-ssh-helper.d/config.hcl
# vault_addr = "https://vault.example.com:8200"
# tls_skip_verify = false
# tls_ca_cert = "/etc/ssl/certs/vault-ca.pem"
# allowed_roles = "otp-admin"

# PAM 設定例（OpenSSH）: /etc/pam.d/sshd に追加
# auth requisite pam_exec.so quiet expose_authtok \
#   /usr/local/bin/vault-ssh-helper -config=/etc/vault-ssh-helper.d/config.hcl

# クライアント（OTP）: OTP を取得して SSH（パスワード認証）
# Vault にログイン済みとする
auth_output=$(vault ssh -mode=otp -role=otp-admin [email protected])
echo "$auth_output"
# 表示された OTP をパスワードとして入力

# 4) CA 署名モード: 署名鍵を生成
vault write ssh/config/ca generate_signing_key=true
# CA 公開鍵を取得し、サーバへ配布
vault read -field=public_key ssh/config/ca > trusted-user-ca-keys.pem

# Role 作成（CA）
vault write ssh/roles/devops \
  key_type=ca \
  allow_user_certificates=true \
  allowed_users=ubuntu \
  default_user=ubuntu \
  ttl=30m \
  allowed_extensions=permit-pty

# サーバ側（CA）: sshd_config の設定
# TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pem
# PubkeyAuthentication yes
# （必要に応じて）AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
# 反映: systemctl reload sshd など

# クライアント（CA）: 自分の公開鍵に署名を取得
vault write -field=signed_key ssh/sign/devops \
  public_key=@$HOME/.ssh/id_rsa.pub > $HOME/.ssh/id_rsa-cert.pub

# 署名付きで接続（鍵＋証明書）
ssh -i $HOME/.ssh/id_rsa -i $HOME/.ssh/id_rsa-cert.pub [email protected]

運用の落とし穴と Associate/Ops 試験の押さえ所

OTP はサーバが認証時に Vault へ到達できないとログインできません。可用性要件に応じて Vault クラスタとネットワーク経路を冗長化します。CA 署名は認証時の到達性を必要としませんが、CA 公開鍵の配布とローテーション手順（ローリング更新と sshd リロード）の整備が肝です。

CA 署名の失効は短 TTL が前提です。個別証明書の中央失効は一般的な OpenSSH ユーザ証明書では難しいため、署名 TTL を短くし、必要に応じて CA 鍵をローテーションします。Vault 側の監査ログで誰がいつどの公開鍵に署名したかを追跡できるようにしておきます。

• Policy の最小権限化: 署名パス（ssh/sign/role）や Role 管理に不要な write 権限を与えない
• Role で CIDR・ユーザ・TTL を強制。max_ttl を設定して逸脱を防止
• 監査ログを有効化し、署名イベントを相関可能にする
• CA 公開鍵のローテーション手順を標準化。段階的に新旧鍵を併置して切替
• 試験では「サーバ到達性がない→CA」「サーバにヘルパ導入可・細かな元制御→OTP」と即断できるかが鍵

問題で確認

よくある質問