AbsoluteTelnet SSH Client (UI + OpenSSH + PuTTY Compatible)
Overview
By default, SSH clients trust servers using Trust On First Use (TOFU). The first time you connect to a host, its host key is recorded into a list of “known hosts” and trusted for future connections. I’m sure you’ve seen it……. “This is the first time you’ve connected to server X with fingerprint Y” Do you want to connect? Are you SURE? Are you REALLY SURE? Connect once? Save the fingerprint to compare next time? Honestly, many of us just click through this dialog the same way we read and accept ‘terms and conditions’… In other words, we trust without a lot of thought.
In dynamic or managed environments, TOFU does not scale well:
- Hosts are rebuilt or replaced
- Host keys change legitimately
- Users see repeated warnings
known_hostsbecomes difficult to manage
SSH Host Certificates solve this problem by introducing a Host Certificate Authority (Host CA). Instead of trusting individual host keys, the client trusts a CA that signs host keys.
AbsoluteTelnet supports SSH Host CAs using standard OpenSSH and PuTTY-compatible semantics, while also providing a dedicated user interface to manage Host CA trust explicitly.
What Is a Host CA?
A Host CA is an SSH key used to sign server host keys.
When a client trusts a Host CA:
- The server presents a host certificate
- The client validates the certificate signature
- The client verifies hostname matching
- No per-host key acceptance is required.
- No more “KNOWN HOST” lists
- We trust the CA. And if the CA trusts this host, we trust it too!!!
This replaces TOFU (Trust On First Use) with explicit, centralized trust.
Important: The client does not create, renew, or issue host certificates — it only trusts them.
How AbsoluteTelnet Handles Host CAs
Starting with AbsoluteTelnet/SSH 13.16, we support Host CAs in three complementary ways:
- AbsoluteTelnet/SSH Host CA UI (recommended)
- Read only view of OpenSSH CA configuration
- Read only view of PuTTY-CAC CA configuration
If you already have CAs configured in either OpenSSH or Putty, AbsoluteTelnet/SSH will use those CA definitions out of the box without any further changes. You can however configure CA directly in AbsoluteTelnet/SSH or VIEW the OpenSSH and Putty definitions in our UI.
Using the AbsoluteTelnet Host CA User Interface
AbsoluteTelnet provides a dedicated interface for managing trusted Host CAs.
Opening the Host CA Configuration
- Obtain AbsoluteTelnet/SSH 13.16 or higher….
- Navigate to:
Options → Properties → SSH Global→ Configure Host CA - The Host CA list displays all configured authorities
- If already configured in OpenSSH, those entries are shown here as read-only informational records
- If already configured in Putty, those entries are shown here as read-only informational records
- AbsoluteTelnet/SSH native entries can be added, imported, modified or removed.
Adding a Host CA
To add a new Host CA:
- Click Add
- Specify the hostname scope, for example:
server.example.com*.example.com*.prod.example.com
- Paste Host CA public key
- (Optional) Add a descriptive comment
- For verification, AbsoluteTelnet/SSH will display the key type, size, and fingerprint
- Save the entry
This entry tells AbsoluteTelnet:
“Any host matching this pattern and presenting a certificate signed by this CA is trusted.”
Editing or Removing a Host CA
- Select an existing CA entry
- Click Edit to modify:
- hostname patterns
- comments
- Click Remove to revoke trust in that CA
Changes take effect immediately for new connections. Entries originating from OpenSSH and Putty can only be viewed here. They cannot be modified or removed. Please refer to OpenSSH and Putty tools/documentation for the correct methods to modify or remove them.
Hostname Matching and Scope
Hostname patterns behave similarly to OpenSSH:
- Exact hostnames match exactly
- Wildcards apply only within the specified domain
- Trust is limited to the defined scope
Example:
*.example.com
Does not match:
example.net
OpenSSH Compatibility
OpenSSH stores trusted Host Certificate Authority (CA) entries in the
known_hostsfile using the@cert-authoritydirective. AbsoluteTelnet honors these entries and applies the same hostname-matching and trust semantics.
PuTTY Compatibility
PuTTY (specifically the PuTTY CAC fork) stores trusted SSH Host CAs in the Windows Registry as part of its PuTTY CAC configuration. AbsoluteTelnet/SSH also recognizes and honors these trust settings, allowing Host CA trust to be shared across mixed OpenSSH and PuTTY environments.
Authentication Flow with a Host CA
When connecting to a host covered by a trusted Host CA:
- The server presents its host certificate
- AbsoluteTelnet/SSH verifies:
- CA signature
- certificate validity period
- hostname match
- The connection proceeds without a host key prompt
No entry is written to known_hosts.
If a host certificate is missing or invalid, the connection is rejected rather than silently falling back to TOFU.
Interaction with known_hosts
Host CA trust and known_hosts can coexist.
Typical behavior:
| Host Type | Trust Method |
|---|---|
| Hosts with valid certificates | Host CA |
| Legacy hosts | known_hosts |
| First-time uncertified hosts | TOFU (if enabled) |
This enables gradual migration without breaking existing workflows.
Security Considerations
- Host CA trust replaces Trust On First Use (TOFU).
- When a Host CA is trusted, AbsoluteTelnet/ssh no longer prompts to accept individual host keys. Only servers presenting a valid host certificate signed by a trusted CA are accepted.
- All hosts that match the configured scope are trusted when signed by the Host CA.
- Any host whose certificate is signed by a trusted Host CA and whose hostname matches the configured pattern will be trusted. Care should be taken to scope Host CA entries to the intended hostnames or domains.
- Host CA trust is global.
- Trusted Host CAs apply to all SSH connections in AbsoluteTelnet/ssh. Removing a Host CA immediately revokes trust for all matching hosts.
- Host CAs and User CAs serve different purposes.
- Host CAs are used by the client to verify server identities. User CAs are trusted by the server to authenticate users. These roles are distinct and should not be conflated.
- Host certificate validation is strict.
- If a host presents an expired, invalid, or improperly scoped certificate, the connection is rejected rather than falling back to host key prompts.
What This Article Does Not Cover
This article intentionally does not describe:
- How to create or operate a Host CA
- How host certificates are issued or renewed
- Infrastructure automation or provisioning
Those processes vary by environment.
Summary
- Host CAs replace TOFU with explicit trust
- AbsoluteTelnet/SSH provides a first-class UI for managing Host CAs
- OpenSSH and PuTTY Host CA configurations are honored
- No per-host key prompts are required
- If it works with OpenSSH, it works with AbsoluteTelnet
Host certificate trust simplifies SSH host verification while improving security — especially in modern, dynamic environments.