Minimal SSH Server Setup for User Certificates

OpenSSH Server + AbsoluteTelnet SSH Client

Purpose

This article shows the minimal server-side configuration required to enable SSH user certificate authentication when using:

OpenSSH on the server
AbsoluteTelnet as the SSH client

It is intentionally narrow in scope.
It does not describe certificate enrollment workflows, CA operational practices, or enterprise key management, which vary widely by environment.

If your server is configured as described here, and your client already has a valid SSH user certificate, authentication should just work.

What This Setup Enables

With this configuration:

The server trusts a User Certificate Authority (CA)
Users authenticate using CA-signed SSH certificates
Individual user keys do not need to be listed in authorized_keys
Clients such as AbsoluteTelnet and OpenSSH behave the same way

Step 1: Create a User Certificate Authority (One-Time)

On a secure system (often not the SSH server itself, and not a client workstation):

ssh-keygen -f user_ca

This creates:

user_ca – private key (protect carefully)
user_ca.pub – public key (distributed to servers)

Only the public CA key is needed on SSH servers.

Step 2: Configure OpenSSH to Trust the User CA

Copy the CA public key to the server, for example:

sudo cp user_ca.pub /etc/ssh/user_ca.pub

Add the following line to /etc/ssh/sshd_config

TrustedUserCAKeys /etc/ssh/user_ca.pub

Reload the SSH daemon:

sudo systemctl reload sshd

That single directive enables SSH user certificate authentication.

Step 3: (Optional) Verify No Conflicting Restrictions

In many environments, no further changes are required.

However, be aware of the following:

AuthorizedKeysFile is not required for certificate authentication
Existing authorized_keys entries may still work
If AuthenticationMethods is configured, ensure publickey is allowed
If PubkeyAuthentication is disabled, certificates will not work

Minimal, compatible configuration:

PubkeyAuthentication yes

Step 4: Sign a User’s Public Key (Reference Only)

The process for signing a user key varies by organization. Sometimes, this may be done through an enrollment portal, by admins, or during HR onboarding. Regardless, the underlying process is the same and includes at least these steps:

Client generates a public/private key pair for authentication
Client’s public key is enrolled (signed) by the CA to create a certificate
Certificate is returned to the client and used during authentication

On the client computer, at a command line, generate an authentication key with ssh-keygen

ssh-keygen -f my_user_key

This should generate the following files:

my_user_key
my_user_key.pub

Using the certificate authority (CA) key created in step 1 (user_ca), sign the user’s public key

ssh-keygen \
  -s user_ca \
  -I user@example \
  -n username \
  -V +30d \
  my_user_key.pub

This will create a certificate file my_user_key-cert.pub.

Place that file on the client alongside the private and public key files. You should now have:

my_user_key
my_user_key.pub
my_user_key-cert.pub

Client Behavior (AbsoluteTelnet SSH Client)

On the client side:

Configure Absolute to use SSH keys for authentication: Options->Properties->Connection->SSH2->Authentication->Use an SSH key
Click ‘choose’ and select the private key (my_user_key)
Absolute detects the certificate (my_user_key-cert.pub) using standard OpenSSH file conventions
If a certificate is present, it is offered before the raw public key
If the server rejects the certificate, AbsoluteTelnet safely falls back to the raw key
No special server-side configuration is required! Specifically, no entry into authorized_keys is needed.

If the same key and certificate work with OpenSSH, they should work with AbsoluteTelnet as well.

What This Setup Does Not Do

This minimal configuration does not:

Manage certificate enrollment
Distribute certificates to clients
Enforce organizational policy
Replace enterprise PKI systems
Use the Windows Certificate Store

It simply establishes trust in a User CA.

Common Validation Checks

If authentication fails:

Confirm you are using AbsoluteTelnet/SSH version 13.16 or higher. Earlier versions did not support SSH certificates
Confirm TrustedUserCAKeys is set correctly (server sshd_config)
Verify the certificate has not expired (-V option from signing step)
Confirm the certificate principal matches the login user (-n username from signing step)
Check SSH server logs for certificate-related messages

Summary

OpenSSH requires only one directive to trust user certificates
AbsoluteTelnet uses OpenSSH-compatible client behavior
No per-user server configuration is required
Enrollment and lifecycle management are intentionally out of scope