Add an SSH Server With Certificate Auth
Last modified on February 7, 2024
An SSH server is a combination of a specific SSH destination and the credentials to access it. This guide describes how to set up an SSH server with a certificate in the Admin UI.
Using certificate authentication eliminates the need to manage unique key pairs for each of your servers. By using a certificate authority managed by StrongDM, every connection is secured with a short-lived private/public key pair, thus eliminating the risk of lost keys being compromised.
Before you begin, ensure that the server you are attempting to add is accessible from your StrongDM gateways or relays. You must have a properly functioning gateway or relay up and running, and it must be able to reach the target server before you can proceed.
To verify, go to the gateway or relay server and from a command prompt, type
ping <YOUR_HOSTNAME>. If your gateway or relay can connect to this hostname, you can continue.
For more information see nodes.
Review StrongDM CA Public Key
Every organization in StrongDM is automatically assigned a unique Certificate Authority (CA). This is a cryptographic key pair in charge of issuing and validating certificates for every SSH session. You need to add the SSH CA public key as a trusted source on any hosts you want to access with this option.
The SSH CA public key can be seen under Network > Certificate Authorities > StrongDM SSH Certificate Authority. The StrongDM SSH Certificate Authority page shows all certificates issued by the CA. Each certificate is identified by a unique fingerprint and the time and date when it was created.
Your organization may have multiple certificates for each CA, but only one SSH certificate and one RDP certificate may be active at any given time. An active certificate is the one configured to authenticate to the resource. The active certificate is highlighted and shown in blue, whereas inactive certificates are shown in gray.
Only one active SSH CA is permitted per organization. If the CA is rotated, all SSH sessions using the last active CA are terminated. Please rotate with caution.
Certificate rotation may be done in the Admin UI only from Network > Certificate Authorities. For more information, please see Certificate Authorities.
How to view and copy the SSH CA public key
- Log in to the StrongDM Admin UI.
- Go to Network > Certificate Authorities > StrongDM SSH Certificate Authority.
- From the StrongDM SSH CA’s Settings tab, select one of the certificates shown, or create a new certificate.
- Click the i button beside the certificate’s fingerprint.
- From the SSH Certificate dialog that displays, use the Copy button to copy the SSH CA public key to your clipboard.
Add the StrongDM CA to Your Host
The next step is to tell your host to trust certificates issued by your organization’s CA. If you have not already, add your organization’s SSH CA public key to the targeted host.
/etc/ssh/sdm_ca.pubfile and add the SSH CA public key.
SSH can sometimes be unpredictable if permissions are not set correctly. Therefore, update the file’s permissions:
sudo chmod 600 /etc/ssh/sdm_ca.pub
With your editor of choice, modify
/etc/ssh/sshd_configby appending the following lines:
# StrongDM CA TrustedUserCAKeys /etc/ssh/sdm_ca.pub
Restart the SSH service on this host for the changes to take effect. Note that the command you execute may differ based on your system configuration, and you may need to restart
ssh, as in the following example:
sudo systemctl restart ssh
Restrict access by username
Because the certificates generated by the CA use the resource settings, anyone with access to modify these settings can change the username and thus elevate their privileges, allowing them to assume root or any existing account on the target system. Of course, any actions are logged by StrongDM. However, we still strongly recommend disabling SSH access for the root account entirely.
Additionally, you can restrict what users or principals are allowed to authenticate with the CA. Every certificate created by the StrongDM CA contains two principals: the username specified in the datasource settings and the literal string
strongdm. You can use the following steps to restrict access to only this user, replacing
user-one with your desired username.
Create a folder to contain the user files.
With your editor of choice, create a file that matches the desired username, as in the following example. Then type the string
strongdm, save, and close.
sudo vim /etc/ssh/sdm_users/user-one
/etc/ssh/sshd_configand append the following line:
After making these changes, restart the sshd service. It then uses the updated version of the AuthorizedPrincipalsFile.
sudo systemctl restart sshd
You can find additional ways to restrict access by username in Red Hat’s Creating SSH Certificates documentation.
Add an SSH Certificate-Based Server in the Admin UI
To add your new SSH certificate-based server as a StrongDM resource, use the following steps.
- Log in to the Admin UI and go to Infrastructure > Servers.
- Click Add server.
- Select SSH (Certificate Based) as the Server Type and set other resource properties to configure how the StrongDM relay connects to the server via SSH.
- Click create to save the resource.
- Click the resource name to view status, diagnostic information, and setting details. After the server is created, the Admin UI displays that resource as unhealthy until the health checks run successfully. When the resource is ready, the Health icon indicates a positive, green status.
Configuration properties are visible when you add a Server Type or when you click to view the server’s settings. The following table describes the settings available for your SSH (Certificate Based) server.
|Meaningful name to display the resource throughout StrongDM; exclude special characters like quotes (") or angle brackets (< or >)
|Select SSH (Certificate Based)
|Hostname or IP address to which you are connecting, such as
testserver-01.example.org; relay server should be able to connect to your target server or hostname
|Port to connect to the resource; default port value 22
|Automatically generated IP address value in the
127.255.255.254 IP address range; default is
127.0.0.1; preferred bind interface value can be modified later under Settings > Port Overrides
|Automatically generated with a value between 1024 to 59999 as long as that port is not used by another resource; preferred port can be modified later under Settings > Port Overrides
|Where the credentials for the server are stored; defaults to Strong CA; to learn more, see Certificate Authority options
|Signing algorithm with default value set to RSA-2048; other options include RSA-4096, ECDSA-256, ECDSA-384, ECDSA-521, and ED25519; to learn more, see Key Type options
|Select Leased Credentials (default) or Remote Identities
|Displays if Authentication is set to Leased Credentials; enter the username the relay should utilize to connect to the server via SSH (for example,
|Displays if Authentication is set to Remote Identity; enter the username that will be utilized to verify StrongDM’s connection to the server; username must exist on the target server
|Resource tags consisting of key-value pairs
<KEY>=<VALUE> (for example,
Certificate Authority options
By default, server credentials are stored in Strong CA. The Strong CA is configured in the Admin UI’s Certificate Authorities page. For more information, please see Certificate Authorities.
Key type options
The following table describes the different key types StrongDM can use to encrypt and secure SSH connections.
|2048-bit key generated with RSA algorithm
|Lowest security guarantees, but has broad support across hosts
|4096-bit key generated with RSA algorithm
|Slightly better than RSA-2048; still uses RSA, but larger keys can prolong the time to crack if an attacker gains access
|Key generated with 256-bit elliptic curve and ECDSA algorithm
|Provides better security guarantees than RSA
|Key generated with 384-bit elliptic curve and ECDSA algorithm
|Slightly better than ECSDA-256
|Key generated with 521-bit elliptic curve and ECDSA algorithm
|Serves as the best ECDSA choice from a security standpoint
|Key generated with ED25519 algorithm
|Provides the best performance and comparable security to ECDSA; much smaller keys, but not as widely supported as other options
- You may have an existing CA key pair and certificate to perform direct SSH or other tasks. You can continue to use this key pair, but you cannot import this CA into StrongDM.
- You do not need to sign these keys, or any user keys. StrongDM handles that for you and for your users.
- Session-based certificates for users are automatically renewed every 3 minutes.