Short-Lived Cert Server Configuration

Cloudflare Access can replace traditional SSH key models with short-lived certificates issued to your users based on the token generated by their Access login.

Access short-lived certificates replace legacy public key authentication flows in SSH access. In traditional models, users generate a keypair and commit their public key into an infrastructure management tool, like Salt, or otherwise upload it to an administrator. Cloudflare Access removes that burden on the end user while also improving security of access to infrastructure with ephemeral certificates.

How does it work?

Cloudflare Access uses the concept of an “application” to represent a resource you protect behind Access. An application consists of a hostname, typically a subdomain you generate, that is used to reach the target resource. Access then generates a public key, signed by Cloudflare that is scoped to your application.

Cert Flow

When users authenticate to a resource over SSH, they use the Cloudflare command-line tool cloudflared. They are prompted to login with your identity provider. Once authenticated, Access checks the user against the policy you have configured for that application. If the user is permitted to reach the resource, Access generates a JSON Web Token (JWT), signed by Cloudflare and scoped to the user and application. Access distributes that token to the user’s device through cloudflared and stores it locally.

cloudflared then generates a keypair with the JWT and sends a request with the application public key to a certificate signing endpoint. Access validates the keypair and generates an ephemeral certificate that is returned to the client. cloudflared then initiates the SSH session with that short-lived certificate. These steps are entirely transparent to the user and require no unique SSH commands, wrappers, or flags.

Cert Gen

On the server, administrators save their public key as a TrustedUserCAKeys file in their SSHD configuration. When the server receives the request, it validates the short-lived certificate against that public key and, if authentic, authorizes the user identity to a matching Unix user.

What are the advantages over a legacy model?

  • Organizations control the keys that have access to their infrastructure. Instead of user-generated certificates securing core resources, Access issues short-lived certificates based on a login with your SSO identity provider.

  • Certificates live for minutes, not years. In most organizations, a user will generate a public key and it will go unchanged for years.

  • Lower risk of device loss or compromise. A stolen device can still contain SSH keys that can be used to access infrastructure. Unless protected by a password, a malicious user can exploit that before an organization has time to revoke both the user identity login and the SSH key that user generated.

  • Consolidate access control and offboarding or revocation. Cloudflare Access controls who can reach sensitive resources using your SSO identity provider. When users authenticate with your identity provider, Access generates a JSON Web Token (JWT) scoped to the user and the application.

  • Comprehensive audit logs. Regardless of your infrastructure, whether on-prem, hybrid, or public cloud, administrators can control who can reach what environments in a single place. Audit logs are collected by Cloudflare Access and standardized across any protected resources. Administrators have the information to know who accessed what and when for any infrastructure behind Access.

How can it be configured?

1. Secure a Server behind Cloudflare Access

To protect a resource behind Cloudflare Access, first follow the instructions here to secure the server.

2. Generate a Short-Lived Certificate Public Key

In the Access dashboard, navigate to the “Short-Lived Certificates” card. In the drop-down on the right, choose the application that represents the resource you secured in Step 1.

New Cert

Click “Generate certificate” and a modal will appear with a public key scoped to your application. Save the key or keep it somewhere convenient for configuring your server.

Pub Key Cert

You can return to copy the public key any time in the dashboard card.

Dash Card

3. Ensure Unix Usernames Match User SSO Identities

Cloudflare Access will take the identity from a token and, using short-lived certificates, authorize the user on the target infrastructure. Access matches based on the identity that precedes an email domain.

For example, if the user’s identity in your Okta or GSuite provider is “[email protected]” then Access will look to match that identity to the Unix user “jdoe”.

For testing purposes, you can run the following command to generate a Unix user on the machine:

$ sudo adduser jdoe

4. Save your Public Key

Save the public key generated from the dashboard in Step 2 as a new .pub file in your system. Use the following command to change directories to the SSH configuration directory on the machine.

$ cd /etc/ssh

Once there, you can use the following command to both generate the file and open a text editor to input the public key.

$ vim ca.pub

In the ca.pub file, paste the public key generated in Access without any modifications. Save the file. In some systems, you may need to use the following command to force the file to save depending on your permissions.

:w !sudo tee %
:q!

5. Modify your SSHD Config

Cloudflare Access requires two changes to the SSHD config file used on the target machine. The first change requires that you uncomment a field already set in most default configurations; the second change adds a new field.

While staying within the “/etc/ssh” directory, open the "sshd_config" file.

$ vim /etc/ssh/sshd_config

Navigate to the row named “PubkeyAuthentication”. In most default configurations, the row will appear uncommented as follows.

# PubkeyAuthentication yes

Remove the # symbol to uncomment the line; keep the setting “yes” enabled.

Next, add a new line below “PubkeyAuthentication” as follows:

TrustedUserCAKeys /etc/ssh/ca.pub

The change above will tell your SSH configuration to use the public key saved in Step 5 for authorizing users. Save the file and quit the editor. You might need to use the following command again to save and exit.

:w !sudo tee %
:q!

6. Restart your SSH Server

Once you have modified your SSHD configuration, you still need to restart the SSH service on the machine. Commands are provided below that cover servers running systemd, as well. You can execute both.

$ sudo service ssh restart
$ sudo systemctl restart ssh

7. Configure your Client SSH Config

On the client side, follow the instructions here to configure your device to use Cloudflare Access to reach the protected machine. To use short-lived certificates, you must include the following settings in your SSH config file.

Host vm.example.com
    ProxyCommand bash -c '/usr/local/bin/cloudflared access ssh-gen --hostname %h; ssh -tt %[email protected] >&2 <&1'

Host cfpipe-vm.example.com
    HostName vm.example.com
    ProxyCommand /usr/local/bin/cloudflared access ssh --hostname %h
    IdentityFile ~/.cloudflared/vm.example.com-cf_key
    CertificateFile ~/.cloudflared/vm.example.com-cf_key-cert.pub

You can save time by printing the configuration required for your specific instance with the following cloudflared command.

$ cloudflared access ssh-config --hostname vm.example.com --short-lived-cert