Cloudflare Docs
Cloudflare Zero Trust
Visit Cloudflare Zero Trust on GitHub
Set theme to dark (⇧+D)

Configure short-lived certificates

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. 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. These keys can remain unchanged for months or years.

Cloudflare Access removes the burden on the end user of generating a key, while also improving security of access to infrastructure with ephemeral certificates.

​​ 1. Secure a server behind Cloudflare Access

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

​​ 2. 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.

In order to match a user to their SSO identity, the user’s Unix username must match their email address prefix. For example, jdoe must be registered in your Okta or GSuite organization as [email protected].

You can create a user entry with duplicate uid, gid, and home directory to link an identity to an existing user with a different username. You will need to create a password for it separately and add it to the same groups to replicate permissions.

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

$ sudo adduser jdoe

​​ 3. Generate a short-lived certificate public key

  1. On the Zero Trust dashboard, navigate to Access > Service Auth.

  2. In the dropdown, choose the application that represents the resource you secured in Step 1.

    New Cert

  3. Click Generate certificate. A row will appear with a public key scoped to your application.

  4. Save the key or keep it somewhere convenient for configuring your server. You can return to copy this public key any time in the Service Auth dashboard.

    Pub Key Cert

​​ 4. Save your public key

  1. Copy the public key generated from the dashboard in Step 2.
  1. Use the following command to change directories to the SSH configuration directory on the remote target machine:

    $ cd /etc/ssh
  2. Once there, you can use the following command to both generate the file and open a text editor to input/paste the public key.

    $ vim
  3. In the file, paste the public key without any modifications.

    The file can hold multiple keys, listed one per line. Empty lines and comments starting with # are also allowed.

  4. 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 %

​​ 5. Modify your SSHD config

The following procedure makes two changes to the sshd_config file on the remote target machine. The first change requires that you uncomment a field already set in most default configurations; the second change adds a new field.

  1. While staying within the /etc/ssh directory on the remote machine, open the sshd_config file.

    $ vim /etc/ssh/sshd_config
  2. Navigate to the row named PubkeyAuthentication. In most default configurations, the row will appear commented out as follows:

    # PubkeyAuthentication yes
  3. Remove the # symbol to uncomment the line; keep the setting yes enabled.

  4. Next, add a new line below PubkeyAuthentication as follows:

    TrustedUserCAKeys /etc/ssh/

    Save the file and quit the editor. You might need to use the following command again to save and exit.

    :w !sudo tee %

​​ 6. Restart your SSH server

Once you have modified your SSHD configuration, you still need to restart the SSH service on the remote machine.

​​ Debian/Ubuntu

$ sudo service ssh restart
$ sudo systemctl restart ssh

​​ CentOS/RHEL

$ sudo service sshd restart
$ sudo systemctl restart sshd

​​ 7. Connect as a user

​​ Configure your client SSH config

On the client side, follow this tutorial 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.

To save time, you can use the following cloudflared command to print the required configuration command:

cloudflared access ssh-config --hostname --short-lived-cert

If you prefer to configure manually, these are the required commands:

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

​​ Connect through a browser-based terminal

End users can connect to the SSH session without any configuration by using Cloudflare’s browser-based terminal. Users visit the URL of the application and Cloudflare’s terminal handles the short-lived certificate flow. To enable, follow the instructions here.

Your SSH server is now protected behind Cloudflare Access — users will be prompted to authenticate with your identity provider before they can connect. You can also enable SSH command logging by configuring a Gateway Audit SSH policy.