Step-by-Step: Using Secure Keys (FIDO/WebAuthn) with AbsoluteTelnet/SSH

This guide walks you from zero → working login using OpenSSH Secure Keys (sk-ssh-*) on a hardware token (YubiKey, Nitrokey, SoloKey, Google Titan, etc.) with AbsoluteTelnet/SSH.

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

Insert the FIDO2 key into USB (or pair NFC/BLE if applicable).
If you haven’t set a PIN, do that now using your vendor’s app (recommended).
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 you will be prompted to:

Touch the key (user presence)
Enter your key PIN (if set)
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:

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

 type %USERPROFILE%\.ssh\id_ed25519_sk.pub

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:

Open (or create) your connection profile for the host.
Go to the Authentication settings (Options->Properties->Connection->SSH2->Authentication)
Select the specific stub file you created, e.g.: C:\Users\<you>\.ssh\id_ed25519_sk (Choose the stub, not the .pub.)
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

Connect to the server with your AbsoluteTelnet profile.
When prompted:
- Touch the key when its LED flashes.
- Enter the PIN if your token requires it.
You should see a successful login using: sk-ssh-ed25519@openssh.com or sk-ecdsa-sha2-nistp256@openssh.com

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 "label@host" during ssh-keygen to tag your key in authorized_keys.
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