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_hosts becomes 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:

1. AbsoluteTelnet/SSH Host CA UI (recommended)
2. Read only view of OpenSSH CA configuration
3. 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

1. Obtain AbsoluteTelnet/SSH 13.16 or higher….
2. Navigate to:
   Options → Properties → SSH Global→ Configure Host CA
3. 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:

1. Click Add
2. Specify the hostname scope, for example:
   • server.example.com
   • *.example.com
   • *.prod.example.com
3. Paste Host CA public key
4. (Optional) Add a descriptive comment
5. For verification, AbsoluteTelnet/SSH will display the key type, size, and fingerprint
6. 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_hosts file using the @cert-authority directive. 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:

1. The server presents its host certificate
2. AbsoluteTelnet/SSH verifies:
   • CA signature
   • certificate validity period
   • hostname match
3. 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:

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.

The post Configuring SSH Host CA Trust appeared first on Celestial Software.

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

The post Minimal SSH Server Setup for User Certificates appeared first on Celestial Software.

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:

1. If a valid certificate is present, AbsoluteTelnet offers the certificate-backed key first
2. If the server rejects the certificate, AbsoluteTelnet falls back to the raw public key
3. 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.

The post Using SSH Certificates with File-Based User Keys appeared first on Celestial Software.

Important behavior: AbsoluteTelnet does not generate or auto-discover Secure Keys. You must create the key stub with ssh-keygen, then tell Absolute which stub file to use for a given host.

1) Prerequisites

Hardware

• A FIDO2/WebAuthn security key (e.g., YubiKey 5/Key-Series, SoloKey, Nitrokey FIDO2, Titan).
• Optional but recommended: set a PIN on the key using the vendor’s tool.

Software on Windows

• Windows 10/11 typically includes the OpenSSH Client out of the box.
• Verify OpenSSH version supports security keys: ssh -V You need OpenSSH 8.2 or later for -t ed25519-sk / -t ecdsa-sk keys.
• If your build is older or lacks “-sk” support:
  • Update via Settings → Optional features (Windows OpenSSH Client), or
  • Install a current OpenSSH release (e.g., via winget or vendor package).

Server

• The SSH server (usually Linux/OpenSSH) must be OpenSSH 8.2+.
• Ensure PubkeyAuthentication yes and your account is allowed to use public keys.

2) Plug in and prepare your security key

1. Insert the FIDO2 key into USB (or pair NFC/BLE if applicable).
2. If you haven’t set a PIN, do that now using your vendor’s app (recommended).
3. Keep the key handy; you’ll be asked to touch it, and possibly enter the PIN, during key creation and at login.

3) Create a Secure Key (stub + public key) with ssh-keygen

In PowerShell or cmd on Windows, execute one of the following commands to generate keys. The key-generation step produces two files: the stub file (which your client uses and remains local) and the .pub file (which you place on the server). The stub holds the reference to your hardware key — you’ll tell AbsoluteTelnet to load that stub. ssh-keygen is included with OpenSSH in Windows 11, and may require an optional install on Windows 10. If the following commands fail, you may need to install or upgrade OpenSSH.

Option A (recommended): Ed25519 Secure Key

ssh-keygen -t ed25519-sk -f %USERPROFILE%\.ssh\id_ed25519_sk

Option B: ECDSA P-256 Secure Key

ssh-keygen -t ecdsa-sk -f %USERPROFILE%\.ssh\id_ecdsa_sk

During creation:

• If windows offers to save to ‘your Windows device’, click ‘change’ and choose ‘Security key’
• Enter your key PIN (if set)
• Touch the key when asked (proves user presence)
• Optionally set an SSH key passphrase (separate from the token PIN)

Resulting files:

• Stub file (private metadata + FIDO credential reference):
  • C:\Users\<you>\.ssh\id_ed25519_sk (or id_ecdsa_sk)
• Public key to place on the server:
  • C:\Users\<you>\.ssh\id_ed25519_sk.pub (or id_ecdsa_sk.pub)

Note on “resident” keys: You can add -O resident if you want the credential stored on the token, but AbsoluteTelnet still requires the stub file path, so resident mode is optional.

4) Install your public key on the server

Copy the .pub file contents to the server user’s authorized_keys:

1. From the command prompt in windows, display the public key:

 type %USERPROFILE%\.ssh\id_ed25519_sk.pub

It should look something like this:

2. On the server (as the target user), append the line to: ~/.ssh/authorized_keys

Create the folder if missing:

mkdir -p ~/.ssh chmod 700 ~/.ssh

Append your new public key to authorized_keys

echo "your public key string" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

You’re done on the server side.

5) Tell AbsoluteTelnet which stub to use

In AbsoluteTelnet/SSH:

1. Open (or create) your connection profile for the host.
2. On Options->Properties->Connection->SSH2, enter the hostname, port, and username for the connection
3. Go to the Authentication settings (Options->Properties->Connection->SSH2->Authentication)
4. Enable ‘use rsa/dsa key to log in’, click ‘choose’ and select the specific stub file you created, e.g.: C:\Users\<you>\.ssh\id_ed25519_sk (Choose the stub, not the .pub.)
5. Save the profile.

Behavior: AbsoluteTelnet uses exactly the stub you select for that host. There’s no automatic key discovery or fallback, by design.

6) Connect and authenticate

1. Connect to the server with your AbsoluteTelnet profile.
2. When prompted:
   • Enter the PIN if your token requires it.
   • Touch the key when its LED flashes.
3. You should see a successful login using: [email protected] or [email protected]

7) Common variations (optional)

• Multiple hosts: Create one stub per host or reuse a stub across hosts—but configure each AbsoluteTelnet profile to point to the intended stub file explicitly.
• Key comments: Add -C "This is a comment" during ssh-keygen to add additional information to the key
• Touch-required policy: You can enforce touch on every use with -O verify-required during keygen (server must support it).

8) Troubleshooting

“Permission denied (publickey)”

• Confirm the .pub line is in the server’s ~/.ssh/authorized_keys for the correct user.
• File permissions: ~/.ssh → 700, authorized_keys → 600.
• Server OpenSSH version is 8.2+.

No touch prompt / token not lighting up

• Ensure the token is seated properly.
• Try a different USB port (avoid hubs first).
• Make sure no vendor app is “exclusively” holding the device.

PIN prompt doesn’t appear / PIN rejected

• Verify or reset the token PIN with your vendor’s tool.
• Too many wrong attempts can lock the key (FIDO standard). Follow vendor recovery.

Multiple tokens inserted

• Remove extras so the right key gets used for signing while you test.

9) Security notes

• The private key material never leaves the hardware token.
• Secure Keys require user presence (touch) and optionally PIN, providing strong phishing resistance.
• This is in addition to AbsoluteTelnet’s long-standing support for PKI smart cards and GSSAPI/Kerberos. Use the method that best fits your environment.

10) Quick reference (Windows paths & commands)

# Create Secure Key (stub + public key)
ssh-keygen -t ed25519-sk -f %USERPROFILE%\.ssh\id_ed25519_sk   # or: -t ecdsa-sk

# Show public key (copy this to server’s authorized_keys)
type %USERPROFILE%\.ssh\id_ed25519_sk.pub

# On the server (Linux/OpenSSH):
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "<paste public key line here>" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

The post Step-by-Step: Using Secure Keys (FIDO/WebAuthn) with AbsoluteTelnet/SSH appeared first on Celestial Software.

This update brings AbsoluteTelnet into alignment with the security model used by recent OpenSSH releases, while preserving Absolute’s long-standing emphasis on user-controlled, predictable authentication.

What Are Secure Keys (sk-ssh)?

Secure Keys are a special class of SSH keys where the private key is stored entirely inside a FIDO2/WebAuthn hardware token such as a YubiKey, Nitrokey, SoloKey, Google Titan, and others.

Supported formats include:

• [email protected]
• [email protected]

Secure Keys differ from traditional SSH keys in important ways:

• The private key is non-exportable
• Each authentication requires explicit user presence (touch or biometric)
• A PIN may be required depending on the token
• Authentication operations are performed inside the hardware device

These formats were introduced in OpenSSH 8.2 and are increasingly used for hardened SSH authentication policies.

How Secure Keys Work in AbsoluteTelnet

AbsoluteTelnet follows the standard OpenSSH implementation model for Secure Keys:

You must generate the Secure Key using OpenSSH (ssh-keygen)

Before AbsoluteTelnet can use a Secure Key, you will need:

• A FIDO2/WebAuthn hardware authenticator
• The device plugged into USB (or paired via NFC/Bluetooth)
• Access to OpenSSH’s ssh-keygen tool

Modern Windows systems already include OpenSSH:

• Windows 10 includes an optional OpenSSH client you can enable under Settings → Apps → Optional Features
• Windows 11 ships with the OpenSSH client enabled by default

This makes it simple to create Secure Keys directly on Windows without installing additional software.

Open a Command Prompt or PowerShell window and run:

ssh-keygen -t ed25519-sk

or:

ssh-keygen -t ecdsa-sk

During creation, OpenSSH will:

1. Prompt you to touch your hardware key
2. Ask for a PIN if your device requires one
3. Create a non-exportable private credential inside the authenticator
4. Generate two files:

• a Secure Key stub file (public metadata + FIDO credential reference)
• a matching .pub file for placement in authorized_keys on the server

The stub file stays on the client, the public key goes on the server, and the private key never leaves the hardware.

AbsoluteTelnet requires this stub file for authentication

AbsoluteTelnet does not automatically discover, enumerate, or generate Secure Keys.
Instead, you select the specific stub file you want to use for a given connection.

Only the stub you choose is used — there is no automatic key fallback or probing, ensuring behavior is clear, deliberate, and predictable.

Authentication is performed by the hardware token

When the server requests authentication, AbsoluteTelnet:

• Loads the selected stub
• Interacts with the FIDO device
• Prompts you for user presence (touch)
• Prompts for PIN if required
• Submits the resulting signature to the server

This workflow matches OpenSSH’s behavior exactly.

Why Add Secure Keys When PKI Was Already Supported?

AbsoluteTelnet has offered hardware-backed authentication for many years through:

• PKI smart cards
• GSSAPI/Kerberos authentication

These systems remain fully supported.

Secure Keys do not replace PKI — they are a separate modern option with several unique advantages:

Modern, platform-neutral hardware

Works with inexpensive, widely available FIDO2/WebAuthn devices.

User-presence enforcement

Every signature requires a physical touch or biometric confirmation.

Portable and convenient

The private credential lives on the hardware token;
the client uses the stub, and the server uses the public key.

Seamless interoperability with OpenSSH

Secure Keys are increasingly adopted in hardened environments and cloud-managed infrastructures.

Available Today

Secure Key support is included in version 13.14 of AbsoluteTelnet/SSH.

This initial implementation focuses on:

• Full compatibility with the OpenSSH sk-ssh-* formats
• PIN and user-presence handling
• Explicit, per-host stub selection
• On-device signing via FIDO hardware

What’s Coming Next

This update lays a solid foundation for future improvements, including:

• Optional Secure Key creation directly within AbsoluteTelnet
• Improved stub-file management and UI integration
• Resident-key enumeration on supported devices
• Smart-card + FIDO hybrid authentication
• PIN caching (with appropriate security controls)

All enhancements will align with AbsoluteTelnet’s core principle:
authentication that is user-controlled, transparent, and predictable.

The post Introducing Secure Key (FIDO/WebAuthn) Support in AbsoluteTelnet/SSH appeared first on Celestial Software.

This upgrade brings faster performance on all platforms, improved security, and broader compatibility with modern OpenSSH servers — especially on systems where AES acceleration is limited.

What Is ChaCha20-Poly1305?

ChaCha20-Poly1305 is an AEAD cipher (Authenticated Encryption with Associated Data) designed for high performance and robust security. Originally deployed by Google and later adopted by OpenSSH, it offers:

• Excellent performance on systems without AES-NI hardware acceleration
• Consistent timing behavior that helps reduce side-channel risk
• A combined encryption + authentication design for improved efficiency
• Strong, modern cryptography that meets current security recommendations

If you’ve ever used SSH from a virtual machine, embedded hardware, or older CPU, ChaCha20 often outperforms AES dramatically.

Why This Matters for AbsoluteTelnet Users

With ChaCha20-Poly1305 enabled:

• Connections feel snappier, especially on older or lightweight machines.
• Battery life improves on mobile or low-power hardware due to reduced CPU overhead.
• Security increases, thanks to modern AEAD design and constant-time behavior.
• Compatibility improves, since OpenSSH servers increasingly default to ChaCha20-Poly1305 as a top-tier cipher.

AbsoluteTelnet automatically negotiates the best algorithm available. When a server offers ChaCha20-Poly1305, the client can now take advantage of it immediately.

Terrapin-Safe Implementation

ChaCha20-Poly1305 interacts closely with the SSH sequence-number behavior highlighted in the Terrapin vulnerability (CVE-2023-48795).
To ensure safe use of AEAD ciphers:

• AbsoluteTelnet automatically checks for Strict KEX support.
• If the server is missing critical protections, the client warns the user, offers automatic remediation, or gracefully falls back to safer algorithms.

This keeps your connection both fast and secure — without guesswork.

Available Today

ChaCha20-Poly1305 support is available now in the latest release of AbsoluteTelnet/SSH.
No configuration change is required — simply connect to a server that supports it, and AbsoluteTelnet will negotiate it automatically (or let you know if there’s a configuration mismatch).

For best results, ensure your server’s SSH implementation is up to date with support for:

• [email protected]
• Strict KEX (RFC 8308)

Learn More

• Terrapin Vulnerability Info
• Deprecated Algorithms
• Compatible Algorithm Reference

The post ✅ ChaCha20-Poly1305 Now Available in AbsoluteTelnet/SSH appeared first on Celestial Software.

What’s New in 13.13

1⃣ AEAD Encryption for Performance and Security

AbsoluteTelnet now includes full support for authenticated encryption with associated data (AEAD), including AES-GCM and other modern modes.
AEAD ensures both confidentiality and integrity while reducing CPU overhead, leading to faster and more secure connections. This update is fully compatible with a wide range of SSH implementations — OpenSSH, Dropbear, and others — ensuring seamless interoperability across platforms.

2⃣ Hybrid Post-Quantum Key Exchange (PQ KEX)

Version 13.13 adds support for hybrid post-quantum key exchange algorithms, combining the best of classical elliptic-curve cryptography with quantum-resistant methods.

Now supporting:

• ML-KEM (Kyber) — the NIST-standardized key encapsulation mechanism for quantum-safe encryption
• sntrup761 (NTRU Prime) — a compact, efficient lattice-based algorithm widely deployed by OpenSSH

These algorithms protect session keys from potential quantum decryption in the future, while maintaining full backward compatibility with existing servers. Whether you connect to modern OpenSSH deployments or mixed environments, AbsoluteTelnet 13.13 negotiates the strongest possible key exchange automatically.

3⃣ Optimized SFTP Transfer Throughput

SFTP now supports virtually unlimited window sizes, enabling dramatically higher throughput for single-channel transfers. You’ll notice faster upload and download speeds, smoother directory browsing, and much better efficiency over high-latency or high-bandwidth connections.

4⃣ User Interface and Quality Improvements

• Modernized tab control with per-monitor DPI awareness
• Cleaner font rendering and layout precision
• Smarter defaults for common SSH and SFTP settings

Still the Most Flexible Windows SSH Client

AbsoluteTelnet continues to deliver the broad feature set professionals depend on:

• SSH1 / SSH2, Telnet, Serial, and TAPI connections
• Smart card, Kerberos, and GSSAPI authentication
• VBScript automation for complex workflows
• Configurable fonts, color schemes, and key mappings

Whether you’re managing enterprise infrastructure or connecting to embedded systems, AbsoluteTelnet/SSH provides the speed, flexibility, and security your work demands.

Why Professionals Choose AbsoluteTelnet Over PuTTY

AbsoluteTelnet isn’t just another terminal client — it’s a professional-grade SSH solution.
Compared to PuTTY, it offers:

• Integrated SFTP file transfer
• Smart card and GSSAPI authentication built in
• Full-screen color customization and layout flexibility
• Direct developer support and active maintenance

Get Version 13.13 Today

Try AbsoluteTelnet/SSH free for 30 days or upgrade your existing license today:
Download AbsoluteTelnet 13.13
Buy Now

Existing customers can install this version directly over their current installation — all preferences and licenses remain intact.

System Requirements

• Windows 10 / 11 / Server 2016 and newer
• 64-bit CPU recommended for optimal performance

About Celestial Software

Celestial Software develops professional-grade communication tools for Windows, including AbsoluteTelnet/SSH, used worldwide across IT, manufacturing, retail, and hospitality sectors.
Visit www.celestialsoftware.net for downloads, documentation, and support.

The post 📰 AbsoluteTelnet/SSH 13.13 Released — Faster, Smarter, and Post-Quantum Ready appeared first on Celestial Software.

• 1Password SSH agent: Use keys from your 1Password vault—no plaintext keys on disk.
• Click-to-connect bookmarks: Store ssh:// or sftp:// URLs in 1Password items; clicks open AbsoluteTelnet.
• Developer Mode logs: Turn on 1Password’s Developer Mode to see agent activity when troubleshooting.

Windows-only for this guide. If you use another agent (OpenSSH or Pageant), those are still supported; this release adds a smooth path for teams already standardized on 1Password.

Read the full setup guide for 1Password + AbsoluteTelnet on Windows →

The post We’ve added first-class support for the 1Password SSH agent on Windows and streamlined ssh:// and sftp:// bookmark launching from 1Password into AbsoluteTelnet/SSH. appeared first on Celestial Software.

This means you can now use your favorite agent—like OpenSSH Agent, PuTTY Pageant, or the 1Password SSH agent—to manage your keys securely. Unlock your private key once and reuse it across all your AbsoluteTelnet sessions without re-entering passphrases.

Why this matters:

• Better security – private keys stay inside the agent process
• Improved convenience – unlock once, connect everywhere
• Seamless compatibility with tools you may already use

We’ve also added support for agent forwarding and 1Password bookmarks, making your workflow even smoother.

Read the full guide here: Using External Authentication Agents with AbsoluteTelnet/SSH

The post AbsoluteTelnet/SSH Adds Support for External Authentication Agents appeared first on Celestial Software.

The post How to connect AbsoluteTelnet/SSH to a Synology NAS device appeared first on Celestial Software.