Scenario

Imagine a team responsible for a large-scale server infrastructure. The primary pain point is the necessity for manual adjustments during personnel or server transactions, as well as the implementation of temporary access limitations for external users like auditors, partners, or others.

A commonly employed approach involves generating SSH keys and injecting the public key into the authorized_keys file on each server.

The conventional approach often lacks the functionality to enforce time-limited key activation. For instance, consider a scenario where a partner requires access to designated machines for 30 days. This necessitates a subsequent manual intervention after 30 days to revoke the key, representing a notably inefficient and resource-intensive methodology.

This document provides a comprehensive, step-by-step procedure for establishing time-restricted customizable SSH access, aimed at securing your server environment and preventing unauthorized access.

These operations are easily automated through the use of any configuration management tool.

Requirements

  • OpenSSH Server
  • OpenSSH Tools (commonly installed with ssh-client)

Short Version

  1. [CENTRAL SERVER] Create the directory
mkdir /etc/ssh/private
  1. [CENTRAL SERVER] Generate the CA with the command below
ssh-keygen -t ed25519 -f /etc/ssh/private/ca

  1. [CENTRAL SERVER] Get the public key of the user and save it to user_key.pub

  2. [CENTRAL SERVER] Generate the key with a time limit for each user.

ssh-keygen -s /etc/ssh/private/ca -I "username" -n "username" -V +24h user_key.pub

  1. [TARGET SERVER] Copy the /etc/ssh/private/ca.pub from the central server to the same directory

  2. [TARGET SERVER] Inject this line below in the /etc/ssh/sshd_config and restart the sshd

TrustedUserCAKeys /etc/ssh/private/ca.pub
  1. [TARGET SERVER] Inject the content of the file user_key-cert.pub into $HOME/.ssh/authorized_keys

Long Story

0. Create the directory

This action is recommended for implementation on both the central server and all target servers.

To maintain and effectively segregate files dedicated to the generated Certificate Authority (CA), it is advisable to create a dedicated directory under /etc/ssh; in this instance, we recommend /etc/ssh/private.

mkdir /etc/ssh/private

1. Generate the Certificate Authority

This action is on the CENTRAL SERVER.

To begin the process, the Certificate Authority (CA) must be generated; this CA will be employed to sign all generated keys.

In this scenario, it will be placed within the /etc/ssh/private directory.

ssh-keygen -t ed25519 -f /etc/ssh/private/ca

It is strongly recommended to assign a passphrase to protect the Certificate Authority (CA).

2. Get the public key of the user

This action is on the CENTRAL SERVER.

For the purposes of this documentation, it is presupposed that the user’s public key is readily available.

Kindly insert the public key’s contents into the file designated as bob.pub.

3. Generate the key with time-limited

This action is on the CENTRAL SERVER. Repeat this task for each user.

ssh-keygen -s /etc/ssh/private/ca -I "<KEY ID, INSERT TIME DATE>" -n "<USER NAME OF THE KEY>" -V +<EXPIRE TIME> /path/to/user.pub

For example:

ssh-keygen -s /etc/ssh/private/ca -I "bob_20250325" -n "bob" -V +24h bob.pub

This command will generate a signed public key, accept the input public key, sign it with the previously generated Certificate Authority (CA), and assign a defined expiration date.

A new file, named bob-cert.pub, will now be created in your current directory.

4. Copy and Inject the CA

This action is the target server. Repeat this task for every target.

Log in to the server using an administrative account to copy and inject the CA. You need only the PUBLIC KEY from the central server.

Copy the file /etc/ssh/private/ca.pub from the central server and insert it in the same directory.

After that, edit the file /etc/ssh/sshd_config and append at the end this line below:

TrustedUserCAKeys /etc/ssh/private/ca.pub

And restart the SSHD deamon.

5. Inject the time-limited public key.

This action is the target server. Repeat this task for every target AND user.

Using an administrative account, append the contents of the previously generated public key, specifically the file bob-cert.pub, to the $HOME/.ssh/authorized_keys file.

6. Test it

Use the private key, which was used to derive the certificate, to perform the test.

For example:

ssh -i bob bob@<target server>