Scaling Infrastructure Security: Implementing an SSH Certificate Authority with Smallstep step-ca for VPS Fleet Management

The Paradigm Shift in Infrastructure Access: Moving Beyond Static SSH Keys

For years, Public Key Authentication has been the gold standard for securing Secure Shell (SSH) access to Virtual Private Servers (VPS). Engineers generate a key pair, append their public key to the ~/.ssh/authorized_keys file on the target server, and gain secure access. However, as an organization scales from a handful of servers to a sprawling multi-cloud VPS infrastructure, this decentralized approach introduces severe operational friction and security vulnerabilities.

Static SSH keys are inherently problematic. They lack a built-in expiration mechanism, meaning a compromised private key grants indefinite access until manually revoked. Tracking down every server containing an ex-employee's public key becomes an administrative nightmare, often resulting in stale access vectors. Furthermore, the practice of "key hoarding" compromises compliance frameworks like SOC 2, ISO 27001, and PCI-DSS. To mitigate these risks, modern enterprise infrastructure demands a shift toward identity-driven, short-lived, passwordless authentication. This is achieved through an SSH Certificate Authority (SSH CA).

Understanding SSH Certificate Authority (CA) Architecture

Unlike traditional SSH key pairs, where servers must pre-register every trusted client key, an SSH CA relies on cryptographic trust chains. The architecture introduces a centralized, trusted entity—the Certificate Authority—which signs public keys, transforming them into temporary certificates.

When utilizing an SSH CA, the workflow shifts completely:

• The Host Trust: Every VPS in your infrastructure is configured to trust the public key of the SSH CA. It no longer needs to maintain an authorized_keys file for individual users.
• The Client Authentication: A developer authenticates against a centralized Identity Provider (IdP). Upon successful authentication, the CA issues a short-lived SSH certificate (e.g., valid for 8 to 16 hours).
• The Handshake: When the developer connects to a VPS, they present the certificate. The VPS validates the certificate's signature against the CA's public key, checks the expiration timestamp, and grants access if valid.

By shifting to certificates, you eliminate key management entirely. When an engineer leaves the company, revoking their access at the IdP level automatically prevents them from obtaining new certificates, instantaneously cutting off access to the entire VPS fleet.

Introducing Smallstep step-ca

While OpenSSH has natively supported certificates for over a decade, managing the underlying CA using raw command-line tools can be error-prone and difficult to automate. This is where Smallstep step-ca comes in. It is an open-source, versatile, and highly secure private certificate authority designed for automated infrastructure. It simplifies certificate issuance, integrates seamlessly with modern identity protocols (OIDC, OAuth, ACME), and provides the robust tooling necessary to run an enterprise-grade SSH CA.

Step-by-Step Deployment: Implementing step-ca for your VPS Infrastructure

Let us walk through the architectural blueprint of setting up Smallstep step-ca to manage SSH access across a production VPS fleet.

Step 1: Installing and Initializing the CA Server

First, designate a secure, isolated VPS or dedicated instance to act as your CA server. Install the step-cli and step-ca binaries on this machine.

# Download and install step-cli
wget [https://github.com/smallstep/cli/releases/download/v0.24.4/step-cli_0.24.4_amd64.deb](https://github.com/smallstep/cli/releases/download/v0.24.4/step-cli_0.24.4_amd64.deb)
sudo dpkg -i step-cli_0.24.4_amd64.deb

# Download and install step-ca
wget [https://github.com/smallstep/certificates/releases/download/v0.24.4/step-ca_0.24.4_amd64.deb](https://github.com/smallstep/certificates/releases/download/v0.24.4/step-ca_0.24.4_amd64.deb)
sudo dpkg -i step-ca_0.24.4_amd64.deb

Once installed, initialize the Certificate Authority. This process generates the root keys and configuration files required to run the daemon.

step ca init --name="Enterprise SSH CA" \
             --dns="ca.internal.net" \
             --address=":443" \
             --provisioner="[email protected]"

During initialization, you will be prompted to choose a password to protect the CA's private keys. Ensure these credentials and the generated root keys are securely backed up, preferably utilizing a Hardware Security Module (HSM) or cloud-native secrets manager for production deployments.

Step 2: Configuring SSH Provisioners

To allow users to obtain certificates, you must configure a provisioner. For an automated, enterprise-ready flow, integrating an OpenID Connect (OIDC) provisioner linked to your IdP (such as Okta, Google Workspace, or Azure AD) is recommended. However, for initial deployment and testing, a standard keypair provisioner can be established:

step ca provisioner add admin-ssh --type JWK

To generate the specific keys used to sign SSH certificates, execute the following command:

step ssh config --ca

This creates the user and host signing keys within your $(step path)/secrets/ directory, separating the duties of signing user access keys from signing host verification keys.

Step 3: Configuring the Target VPS Fleet

Every target VPS must be configured to trust user certificates signed by your new CA. To do this, distribute the CA's public user signing key to every server. You can retrieve this key from the CA server or fetch it securely via the client tool:

step ssh config --host --ca-url [https://ca.internal.net](https://ca.internal.net) --fingerprint 

This command automatically updates your target server's OpenSSH daemon configuration. Behind the scenes, it modifies /etc/ssh/sshd_config by adding the following directive:

TrustedUserCAKeys /etc/ssh/ssh_user_key.pub

To enforce robust principal matching, you should also configure how the server maps certificate identities to local system users. Restart the SSH daemon to apply the changes:

sudo systemctl restart sshd

At this point, the target VPS will completely trust and accept any valid, unexpired SSH certificate signed by your Smallstep CA containing the appropriate principal permissions.

Step 4: Client Provisioning and Access Workflow

On the engineer's local workstation, interacting with the infrastructure becomes remarkably straightforward. The user installs the step CLI tool and authenticates against the CA:

# Login and generate a temporary SSH certificate
step ssh login [email protected] --provisioner admin-ssh

This command triggers the authentication flow, generates a temporary key pair, passes the public key to step-ca, and returns a signed SSH certificate directly into the user's local SSH agent. By default, Smallstep configures this certificate with a strict validity window (e.g., 16 hours).

The engineer can now access any VPS in the fleet using standard SSH commands:

ssh [email protected]

No passwords. No permanent keys. The target VPS independently validates the cryptographic signature of the certificate, matches the identity, and grants access securely.

Security and Operational Best Practices

Deploying an SSH CA drastically reduces your attack surface, but the security of your entire infrastructure now relies heavily on the integrity of the CA itself. Adhere to the following operational guardrails:

• Isolate the CA Server: The VPS hosting step-ca must be heavily restricted. Implement strict firewall rules (Security Groups) allowing access only from your corporate VPN or dedicated IP blocks.
• Enforce Short Lifespans: Do not fall into the trap of issuing long-lived certificates. Restrict client certificates to a maximum of 8-12 hours, forcing a re-authentication cycle at the start of every workday.
• Automate Host Registration: Use configuration management tools like Ansible, Terraform, or Puppet to automatically bootstrap new VPS instances with the CA’s public key upon provisioning.
• Centralize Audit Logging: Forward all step-ca issuance logs and target server /var/log/auth.log streams to a centralized SIEM platform to ensure comprehensive visibility and auditable compliance tracking.

Conclusion

Transitioning from decentralized static keys to a centralized SSH Certificate Authority using Smallstep step-ca represents a massive leap forward in infrastructure security matureness. It effectively mitigates credential theft, simplifies offboarding workflows, eliminates administrative key rotation compliance burdens, and provides engineering teams with a frictionless, truly passwordless access experience. As your VPS infrastructure grows, embedding cryptographic trust chains into your identity strategy ensures your defenses scale seamlessly alongside your compute footprints.