Using SSH Certificates with File-Based User Keys

Client Configuration (OpenSSH-Compatible Behavior)

Overview

SSH user certificates allow you to authenticate using a signed public key instead of managing per-server authorized_keys files. From a client perspective, certificates augment existing SSH keys — they do not replace them.

AbsoluteTelnet implements SSH user certificates using OpenSSH-compatible, file-based behavior. If you already have SSH public key and certificate files set up for OpenSSH, they should work in AbsoluteTelnet without modification.

This article focuses only on client-side configuration for file-based SSH keys.

What Changes When You Use SSH Certificates?

Very little, from the client’s point of view:

Your private key does not change
Your public key does not change
A certificate file is added alongside the public key
The SSH client presents the certificate automatically when available

If the server trusts the signing CA, authentication succeeds.
If it does not, the client can fall back to normal public-key authentication.

File Layout (Standard OpenSSH Convention)

SSH certificates are associated with keys using filenames.

For a file-based key:

id_ed25519
id_ed25519.pub
id_ed25519-cert.pub

Where:

id_ed25519 is the private key
id_ed25519.pub is the public key
id_ed25519-cert.pub is the CA-signed SSH certificate

This is the standard OpenSSH convention, and AbsoluteTelnet uses the same mechanism.

If your files are already named this way and work with OpenSSH, they should work in AbsoluteTelnet as well.

How AbsoluteTelnet Associates Keys and Certificates

AbsoluteTelnet follows OpenSSH client behavior:

A certificate named key-cert.pub is automatically associated with key.pub
No additional configuration is required
Certificates are discovered at connection time

There is no separate “certificate configuration” step on the client.

Authentication Behavior

For each key:

If a valid certificate is present, AbsoluteTelnet offers the certificate-backed key first
If the server rejects the certificate, AbsoluteTelnet falls back to the raw public key
If no certificate exists, the raw key is used directly

This preserves compatibility with:

servers that do not use certificates
mixed environments during migration

Where Files Should Live

Certificates are loaded from the same locations as SSH keys, typically:

~/.ssh/
Any directory already configured for SSH key usage

AbsoluteTelnet does not require a special directory or certificate store for file-based keys.

Common Issues and Checks

Certificate is ignored

Confirm the filename ends with -cert.pub
Verify the certificate has not expired
Check that the certificate matches the public key

Authentication falls back to the raw key

The server may not trust the signing CA
The certificate may not be valid for the requested user (principal mismatch)

Works in OpenSSH but not here

Verify the same key directory is being used
Confirm files are readable by the client
Check connection logs for certificate-related messages

What This Article Does Not Cover

How certificates are issued or signed
Enrollment workflows
Certificate Authorities or lifecycle management
Smart-card-backed SSH keys
Windows Certificate Store usage

These topics vary widely between environments and are documented separately.

Important Note on Windows Certificate Stores

SSH certificates are not X.509 certificates and are not stored in the Windows Certificate Store. AbsoluteTelnet loads SSH certificates using standard OpenSSH file-based mechanisms.

Summary

SSH certificates extend existing file-based SSH keys
AbsoluteTelnet uses OpenSSH-compatible filename conventions
If your key and certificate files already exist, they should just work
Certificates are offered first, with safe fallback to raw keys
No special client-side configuration is required

If you already use SSH certificates with OpenSSH, you can use them with AbsoluteTelnet in the same way.