Short-lived SSH certificates: a new approach to server access
Infrastructure access remains one of the hardest problems in Zero Trust adoption. Organizations have successfully modernized access to web applications, but privileged access to servers, databases, and network devices often still relies on credentials that are long-lived, shared, and poorly tracked.
Cloudflare's Access for Infrastructure — built on the technology it acquired with BastionZero — is designed to close that gap by bringing Zero Trust controls natively into Cloudflare One. The first available capability is short-lived SSH access, with support for Remote Desktop Protocol (RDP), Kubernetes, and databases planned over the coming months.
Why traditional PAM and homegrown key management fall short
Organizations typically tackle privileged access in one of two ways. Traditional Privileged Access Management (PAM) solutions centralize credentials, add session recording, and rotate keys on each use, but this centralization often introduces performance bottlenecks, complicates the user experience, and carries a significant cost. Homegrown tools built on cloud-provider primitives or custom infrastructure-as-code avoid those costs but demand constant maintenance.
Both approaches leave common pain points unresolved:
- Risk from long-lived credentials: Shared keys and passwords get passed around, inflating the risk of compromise, excessive permissions, and lateral movement.
- Operational overhead: Manual credential rotation and weak visibility into infrastructure access slow down incident response and complicate compliance.
Access for Infrastructure treats infrastructure like any other sensitive resource: authentication comes from SSO, MFA, and device posture rather than shared secrets; authorization is policy-based; and auditing provides command logs and session recordings. The features are natively integrated into Cloudflare's Zero Trust Network Access (ZTNA) service rather than bolted on as a separate product.
The problem with SSH credentials
SSH is the primary protocol for administering Linux and Unix servers, and it typically carries elevated privileges — the ability to delete or exfiltrate data, install software, or modify system state. Enterprises often have hundreds or thousands of SSH-accessible targets, making manual credential management impractical. SSH servers are also frequent targets for cryptojacking and proxyjacking attacks, and there is nothing preventing users from copying SSH keys and sharing them with others or moving them to unauthorized devices.
Modern enterprises also operate under compliance obligations. Frameworks including SOC2, ISO 27001, and FedRAMP have criteria that require monitoring who has SSH access and what they do with it. Corporate-network gating alone no longer satisfies these requirements.
How short-lived SSH access works
SSH with Access for Infrastructure replaces passwords and static SSH keys with short-lived certificates issued by a Cloudflare-managed certificate authority (CA). The Cloudflare SSH CA holds a secret signing key that is never exposed, while its public key is available via the Cloudflare API. Target servers are configured to trust that CA, after which they will accept any SSH certificate validly signed by it.
Certificates are issued dynamically for individual users and expire after three minutes. The short window is not a limit on session length — sessions can run arbitrarily longer — but on the time during which the user must authenticate to the target. The 3-minute window is short enough to reduce the risk of stolen certificate reuse yet long enough not to miss the user's authentication attempt even on slow connections.
Because certificates are issued on demand, there are no long-lived SSH keys or passwords to manage, rotate, or lose track of. The same Cloudflare SSH CA serves all users and all targets, eliminating the administrative burden of per-user key management.
The deployment model builds on existing Cloudflare One infrastructure: users connect through the WARP device client, and targets are exposed via Cloudflare Tunnel (cloudflared or the WARP connector). For organizations already running Cloudflare One, the only additional configuration is instructing the target server to trust the Cloudflare SSH CA. End-user workflows are unchanged — SSH with Access for Infrastructure works with whatever native SSH client users already have.
Policy-based access down to the Linux user
With traditional SSH, once a user's key is installed on a server, access persists indefinitely unless an administrator remembers to remove it. That dynamic leads to privilege creep — too many people holding standing access to too many servers, any one of which could be stolen or leaked.
SSH with Access for Infrastructure centralizes this in the Cloudflare dashboard, where administrators write policies specifying exactly which users may access which servers, with authentication enforced through SSO, MFA, device posture, and location.
The certificates themselves include a valid_principals field that indicates the specific Linux user (for example root, read-only, ubuntu, or ec2-user) the SSH connection may assume. Policies can therefore specify not only which end users reach which servers, but which Linux usernames they can log in as — enabling central control over privilege levels on the target. One caveat: the server must already know about the specific Linux user referenced in the policy. Cloudflare manages access, not the local Linux accounts themselves.
This granularity, combined with command logging and session visibility, gives administrators the ability to answer not just who connected, but what they did once connected — a requirement for compliance and a practical tool for incident investigation.
Existing Cloudflare One network controls for SSH remain available. SSH with Access for Infrastructure builds on them, adding authorization for ports, protocols, and specific users, along with an improved deployment workflow and richer audit logging.
Command logging and key management
Cloudflare captures SSH command logs by running an SSH proxy that sits between the end user's SSH client and the target server. The proxy terminates the user's connection and establishes its own connection to the target, which lets it inspect and log every command the user sends. Command logs are encrypted at rest with a public key you upload through the Cloudflare API; Cloudflare never has the corresponding private key, so it cannot read the logs itself. You can retrieve the encrypted logs via the API and decrypt them locally with your private key.
Deploying this setup requires exactly two keys:
- SSH CA public key. Cloudflare holds the private key of the SSH CA. You fetch the public key from the Cloudflare API and install it on every target server, so the servers accept certificates issued by this CA. The same public key is used for all targets and does not need to be kept secret.
- SSH command log encryption key. You generate a public-private key pair and upload only the public half to Cloudflare. This encryption key protects command logs at rest. You must keep the private half secret and use it to decrypt logs retrieved from the API.
Inside the SSH proxy
To see how the proxy works, it helps to recall how a normal SSH session starts. SSH runs on top of TCP, so the client and server first complete a TCP handshake. They then perform an SSH key exchange, which produces an ephemeral symmetric key for encrypting the session. This exchange relies on the server's public key, known as the hostkey. When your SSH client first encounters a hostkey, it asks you to trust it — the Trust On First Use (TOFU) prompt many SSH users have seen.
After the key exchange, the client authenticates itself to the server, typically with a password, an SSH key, or an SSH certificate. SSH also supports a none authentication mode, which means the client does not authenticate at all.
In the Cloudflare model, you first define target servers by IP address or hostname, then create an Access for Infrastructure application that captures TCP ports such as 22, and finally write access policies for those connections. Once configured, Cloudflare intercepts any TCP handshake destined for a known target and routes that traffic to the SSH proxy. The proxy takes the identity the WARP client already established, checks it against your policies, and rejects the connection if the user is not allowed to reach the target under the requested Linux user. If the policy check passes, the proxy opens two separate SSH connections:
- SSH proxy to the target server
- End user's SSH client to the SSH proxy
Proxy to target. Here the proxy acts as the SSH client. Its key exchange with the target uses the target's own hostkey to derive the session's symmetric encryption key. For authentication, the proxy presents a short-lived SSH certificate issued by the Cloudflare SSH CA for the Linux user requested on the connection. The target validates this certificate against the Cloudflare CA public key you installed earlier, and the session is established.
Client to proxy. The proxy acts as the SSH server for the end user's connection. This presents a problem: it needs to offer a hostkey for the key exchange, but the target's actual hostkey corresponds to a private key held only by the target server — the proxy cannot use it. If the proxy simply generated a fresh hostkey each time, the user would be hit with TOFU warnings on every connection. Instead, the proxy derives a deterministic hostkey by hashing a fixed per-account secret together with the target's actual hostkey. This way, the same hostkey appears every time the user connects to a given target, so the TOFU prompt appears only on the first connection. If an attacker changes the target's hostkey, the derived hostkey changes too, and the user sees the usual host-key warning.
Finally, in the client-to-proxy key exchange, the proxy tells the user's SSH client to use none for authentication. There is no password prompt and no SSH key stored on the user's machine. That does not weaken security: the proxy already authenticated the user through the WARP client at the edge, so native SSH authentication is unnecessary. The combined result is that users reach target servers without any SSH keys or passwords, while the native TOFU and host-key warning behaviors are preserved.
