Vault SSH Engine in Practice: Choosing Between OTP and CA Signing

The Vault SSH engine ships with two modes: one-time passwords (OTP) and certificate signing where Vault acts as the SSH CA. The two differ in their network requirements, deployment cost, and revocation strategy.

This article assumes stable behavior as described in the official documentation, and summarizes the design trade-offs, a minimal setup recipe, and the angles most likely to appear on the exam.

Vault SSH Engine Overview and Exam Angles

The Vault SSH engine centralizes SSH access control to servers. It offers two modes: OTP mode, which issues a single-use password to the user, and CA-signing mode, where Vault acts as the SSH certificate authority and attaches a short-lived certificate to the user's public key.

At the Associate/Ops level, expect questions on which mode to choose under which conditions, the server-side configuration requirements, TTL and revocation thinking, use of audit logs, and rotation operations. OTP requires a PAM helper on each server and talks to Vault at authentication time. CA signing only requires configuring the server to trust the CA public key — no Vault call at authentication time.

• OTP is a single-use, short-lived password. The server must be able to reach Vault outbound.
• CA signing issues a short-lived SSH certificate. The server trusts Vault's CA public key via the TrustedUserCAKeys setting.
• Either way, Vault Roles let you centrally manage constraints such as users, CIDRs, and TTLs.

How SSH OTP Mode Works and What It Requires

In OTP mode, the user obtains a single-use password from Vault and uses it as the SSH password. The server side runs a PAM helper such as vault-ssh-helper, which forwards the received password (OTP) to the Vault API to verify it. The OTP is valid only once and is given a short TTL.

On the Vault side, you enable the SSH engine and create a Role with key_type=otp. The Role accepts constraints such as default_user, allowed_users, cidr_list, port, ttl, and max_ttl. Because you can centrally control the source and destination user, this fits short-lived bastion use cases and phased rollouts well.

• Requirement: outbound connectivity from the server to Vault at authentication time.
• Server: integrate vault-ssh-helper into PAM and configure the Vault address and CA.
• Client: obtain an OTP via the vault CLI and supply it as the ssh password.
• Characteristics: single-use, short TTL, helper must be installed on every server.

How SSH CA-Signing Mode Works and What It Requires

In CA-signing mode, Vault holds the signing key as an SSH user CA and issues a certificate — containing the validity period, principals, and so on — for the user's public key. The server trusts Vault's CA public key via TrustedUserCAKeys in sshd_config, and authentication completes purely by verifying the key plus certificate presented at connection time. The server does not need to talk to Vault during authentication.

The Vault-side Role (key_type=ca) controls the signing policy via allowed_users, default_user, ttl/max_ttl, allowed_extensions, default_extensions, allowed_critical_options, and more. Revocation is typically handled through short TTLs and key rotation. Centralized signing dramatically reduces distribution and revocation overhead in large environments.

• Requirement: distribute Vault's CA public key to servers and configure them to trust it.
• Server: set OpenSSH's TrustedUserCAKeys and reload sshd.
• Client: submit your public key to Vault to obtain a short-lived certificate, and connect using the key together with the certificate.
• Characteristics: short TTL, no Vault call at authentication time, well-suited to large-scale operations.

Connection flow for OTP and CA

Comparing OTP and CA: How to Pick

OTP is a strong fit when you want to start with lightweight server-side changes, such as a phased rollout or bastion-only use case. By contrast, CA signing significantly cuts operational overhead in environments with many servers or users. It also wins decisively in offline or zero-trust contexts where reaching Vault at authentication time is undesirable.

Exam questions test whether you can justify the choice along four axes: network reachability, server-side requirements, revocation strategy (TTL and rotation), and the differences in what each Role can control.

• Prioritize ease of initial rollout: OTP.
• Prioritize scale and offline authentication: CA signing.
• Need strict revocation: CA relies on short TTLs and key rotation; OTP is naturally single-use and self-revoking.

Minimal Setup Recipe (OTP and CA)

The following is a minimal example for learning and verification. In production, always enable TLS verification, least-privilege policies, and audit logging. Make sshd configuration changes during a maintenance window, and always keep a separate session open to confirm connectivity.

You can run both OTP and CA on the same Vault instance. Separate Roles by purpose and tighten CIDR, user, and TTL constraints.

• Vault side: enable the SSH engine and create Roles (OTP/CA).
• Server side: install PAM integration for OTP, configure TrustedUserCAKeys for CA.
• Client side: connect with the password for OTP, and with the key + certificate for CA.

Step-by-step: Vault configuration, server configuration, and connecting

# 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]

Operational Pitfalls and Associate/Ops Exam Hotspots

With OTP, logins fail whenever the server cannot reach Vault at authentication time. Make the Vault cluster and network paths redundant in proportion to your availability requirements. CA signing does not require reachability at authentication time, but the discipline that matters most is having a clear CA public-key distribution and rotation procedure (rolling updates plus sshd reload).

Revocation for CA signing assumes short TTLs. Central revocation of individual certificates is hard for typical OpenSSH user certificates, so keep the signing TTL short and rotate the CA key when necessary. Make sure Vault audit logs let you trace who signed which public key and when.

• Least-privilege policies: never grant write permissions on signing paths (ssh/sign/role) or Role management that are not strictly needed.
• Enforce CIDR, users, and TTL on the Role. Set max_ttl to prevent drift.
• Enable audit logging and make sure signing events can be correlated.
• Standardize the CA public-key rotation procedure: stage the cutover by running the old and new keys side by side.
• On the exam, the key is snap-deciding: "no server reachability to Vault → CA" and "helper can be installed and fine-grained source control is needed → OTP".

Check Your Understanding

Frequently Asked Questions