---
title: Short-lived certificates (legacy) · Cloudflare Zero Trust docs
description: Cloudflare Access can replace traditional SSH keys with short-lived certificates issued to your users based on the token generated by their Access login. In traditional models, users generate an SSH keypair and administrators grant access to individual SSH servers by deploying their users' public keys to those servers. These SSH keys can remain unchanged on these servers for months or years. Cloudflare Access removes the burden of managing SSH keys, while also improving security by replacing long-lived SSH keys with ephemeral SSH certificates.
lastUpdated: 2025-02-24T18:50:47.000Z
source_url:
  html: https://9d8cd229.preview.developers.cloudflare.com/cloudflare-one/applications/non-http/short-lived-certificates-legacy/index.md
  md: https://9d8cd229.preview.developers.cloudflare.com/cloudflare-one/applications/non-http/short-lived-certificates-legacy/
---

Note

Not recommended for new deployments. We recommend using [Access for Infrastructure](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/use-cases/ssh/ssh-infrastructure-access/) to configure short-lived certificates for SSH.

Cloudflare Access can replace traditional SSH keys with short-lived certificates issued to your users based on the token generated by their Access login. In traditional models, users generate an SSH keypair and administrators grant access to individual SSH servers by deploying their users' public keys to those servers. These SSH keys can remain unchanged on these servers for months or years. Cloudflare Access removes the burden of managing SSH keys, while also improving security by replacing long-lived SSH keys with ephemeral SSH certificates.

## 1. Secure the server behind Cloudflare Access

Cloudflare Access short-lived certificates can work with any modern SSH server, whether it is behind Access or not. However, we recommend putting your server behind Access for added security and features, such as auditability and browser-based terminals.

To secure your server behind Cloudflare Access:

1. [Connect the server to Cloudflare](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/get-started/create-remote-tunnel/) as a public hostname route.
2. Create a [self-hosted Access application](https://developers.cloudflare.com/cloudflare-one/applications/configure-apps/self-hosted-public-app/) for the server.

Note

If you do not wish to use Access, refer instead to our [SSH proxy instructions](https://developers.cloudflare.com/cloudflare-one/policies/gateway/network-policies/ssh-logging/).

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

The simplest setup is one where a user's Unix username matches their email address prefix. Issued short-lived certificates will be valid for the user's email address prefix. For example, if a user in your Okta or GSuite organization is registered as `jdoe@example.com`, they would log in to the SSH server as `jdoe`.

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

```sh
sudo adduser jdoe
```

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

1. In Zero Trust, go to **Access** > **Service auth** > **SSH**.

2. In the **Application** dropdown, choose the Access application that represents your SSH server.

3. Select **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.

## 4. Save your public key

1. Copy the public key generated from the dashboard in Step 3.

1) Use the following command to change directories to the SSH configuration directory on the remote target machine:

   ```sh
   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.

   ```sh
   vim ca.pub
   ```

3) In the `ca.pub` file, paste the public key without any modifications.

   ```txt
   ecdsa-sha2-nistp256 <redacted> open-ssh-ca@cloudflareaccess.org
   ```

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

4) Save the `ca.pub` file. In some systems, you may need to use the following command to force the file to save depending on your permissions:

   ```bash
   :w !sudo tee %
   :q!
   ```

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

   ```sh
   vim /etc/ssh/sshd_config
   ```

2. Go to the row named `PubkeyAuthentication`. In most default configurations, the row will appear commented out as follows:

   ```txt
   # PubkeyAuthentication yes
   ```

3. Remove the `#` symbol to uncomment the line:

   ```txt
   PubkeyAuthentication yes
   ```

4. Add a new line below `PubkeyAuthentication`:

   ```txt
   TrustedUserCAKeys /etc/ssh/ca.pub
   ```

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

   ```txt
   :w !sudo tee %
   :q!
   ```

## 6. Restart your SSH server

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

* Debian/Ubuntu

  For older Debian/Ubuntu versions:

  ```sh
  sudo service ssh restart
  ```

  For newer Debian/Ubuntu versions:

  ```sh
  sudo systemctl restart ssh
  ```

* CentOS/RHEL

  For CentOS/RHEL 6 and older:

  ```sh
  sudo service sshd restart
  ```

  For CentOS/RHEL 7 and newer:

  ```sh
  sudo systemctl restart sshd
  ```

## 7. Connect as a user

### Configure your client SSH config

On the client side, [configure your device](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/use-cases/ssh/) 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 (`~/.ssh/config`).

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

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

If you prefer to configure manually, this is an example of the generated SSH config:

```txt
Match host vm.example.com exec "/usr/local/bin/cloudflared access ssh-gen --hostname %h"
    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
```

### 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, refer to [Browser-rendered terminal](https://developers.cloudflare.com/cloudflare-one/applications/non-http/browser-rendering/).

***

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](https://developers.cloudflare.com/cloudflare-one/policies/gateway/network-policies/ssh-logging/).
