Using SK keys on login-plus.discoverer.bg

Important

This document does not cover the use of SK keys on Windows systems. The FIDO2/WebAuthn middleware stack — specifically libfido2 and its associated transport layers — exhibits inconsistent behaviour on Windows due to driver compatibility issues and frequent regressions following system updates. This guide is intended for Linux and macOS users only.

Introduction

What SK keys are

SK keys — identified by the key type prefixes sk-ssh-ed25519 and sk-ecdsa-sha2-nistp256 — are SSH key types whose private key material is bound to a FIDO2 authenticator rather than residing as a plain file on the local filesystem. The sk prefix denotes security key.

The underlying cryptographic design is defined in IETF RFC 8812 and the support was introduced in OpenSSH 8.2. When an SK key is used for authentication, the SSH client delegates the signing operation to the FIDO2 authenticator via the libfido2 middleware library. The authenticator performs the signing internally and returns only the signature, never the raw private key material.

Two FIDO2 key types are supported by OpenSSH:

sk-ssh-ed25519@openssh.com — backed by the Ed25519 signing algorithm over Curve25519; recommended
sk-ecdsa-sha2-nistp256@openssh.com — backed by ECDSA over the NIST P-256 curve; acceptable for users subject to NIST compliance requirements, but see Effective security level of SK key types

Note

The @openssh.com suffix in the key type name is an OpenSSH-specific namespace identifier and does not imply a network connection to openssh.com.

How SK keys differ from traditional SSH key pairs

Aspect	Traditional SSH key pair (`ed25519`, `ecdsa`, `rsa`)	SK-backed SSH key pair (`sk-ssh-ed25519`, `sk-ecdsa-sha2-nistp256`)
Private key location	File on the local filesystem (`~/.ssh/id_*`)	Protected memory of the FIDO2 authenticator; never exposed
Signing location	System memory of the client host	Secure processor inside the authenticator
Authenticator presence	Not required	Authenticator must be present and responsive for every operation
Human interaction	Optional passphrase prompt	Physical touch or biometric confirmation required
Key portability	Key file may be copied or backed up	Private key cannot be exported; only the key handle file is portable
Suitability for automation	Yes	No
Compromise risk on compromised host	High — key file accessible to malware or unauthorised users	Low — private key protected even on a compromised host

Operational considerations for SK key users

SK keys are fully supported on login-plus.discoverer.bg. They are, however, less commonly used than traditional key pairs, primarily because they require additional client-side setup and impose constraints that users should be aware of before adopting them.

The FIDO2 authenticator must be physically or logically reachable at the moment of every signing operation. Several practical difficulties follow from this requirement:

Middleware dependency: libfido2 version 1.5.0 or later must be installed on the client host. Older distributions ship with incompatible versions.
Transport dependency for remote authenticators: when the authenticator is not physically attached to the client host (e.g., an Android device used as a software token), the FIDO2 CTAP2 hybrid transport (caBLE) over Bluetooth Low Energy is required. This transport is not universally available in the OpenSSH builds shipped by major Linux distributions.
Rate-limiting interaction: failed authenticator interactions count as failed authentication attempts. If the authenticator does not respond in time, or if the user does not provide the required gesture within the timeout window, the SSH server records a failure. Repeated failures may trigger the server-side rate limiter and temporarily block the originating IP address.
Absence of support in non-interactive workflows: CI/CD pipelines, batch schedulers, and automated data transfer tools cannot satisfy the user-presence requirement imposed by FIDO2. SK keys must not be used in such contexts.

Warning

SK keys cannot be used for passwordless, unattended authentication. Any workflow that requires the SSH client to authenticate without human interaction — including job submission scripts, automated scp or rsync transfers, and SSH tunnelling initiated by background daemons — is incompatible with SK keys. Use a traditional key pair (ed25519 recommended) for such use cases.

Effective security level of SK key types

Both SK key types supported by OpenSSH provide an effective security level of approximately 128 bits:

sk-ssh-ed25519 uses Ed25519, which operates over Curve25519. NIST SP 800-186 (2023) includes Curve25519 as an approved curve, and the security level is approximately 128 bits, equivalent to AES-128.
sk-ecdsa-sha2-nistp256 uses ECDSA over NIST P-256. Per NIST SP 800-57 Part 1 Revision 5, a 256-bit elliptic curve key provides approximately 128 bits of security strength, again equivalent to AES-128.

The two algorithms are therefore equivalent in effective security level. The 128-bit security level is considered adequate for protecting data through at least 2030 under current NIST guidance, though it offers no margin against a cryptographically relevant quantum computer (see NIST SP 800-131A for transition timelines).

Comparison with traditional (non-SK) key pairs of the same algorithm

An sk-ssh-ed25519 key and a traditional ed25519 key are backed by the same elliptic curve arithmetic and therefore have identical brute-force resistance: an attacker attempting to recover the private scalar by exhaustive search faces the same approximately 2¹²⁸ operations in both cases. The same holds for sk-ecdsa-sha2-nistp256 compared to a traditional ecdsa key over NIST P-256.

The security advantage of the SK construction is not in the size of the key but in where the private key resides and how it is used:

For a traditional key pair, the private key scalar exists as a file on the filesystem. An attacker who compromises the client host, or who obtains a copy of the private key file, can use it indefinitely from any machine without the owner’s knowledge.
For an SK key pair, the private key scalar is generated inside the authenticator and never leaves it. An attacker who compromises the client host obtains only the key handle file, which is useless without the physical authenticator. Every use of the key additionally requires explicit user presence (touch or biometric), making silent, remote exploitation of the key impossible.

In short: the SK construction does not increase the cryptographic key size, but it eliminates the entire attack surface associated with key extraction from the filesystem and from memory, and it enforces mandatory human presence for every signing operation.

Note

The FIDO2 CTAP2 specification requires all compliant authenticators to support ECDSA over NIST P-256 as a mandatory baseline algorithm. Ed25519 support is optional in CTAP2. Consequently, some authenticator hardware — particularly older or low-cost devices — may only be capable of generating sk-ecdsa-sha2-nistp256 keys. Users subject to NIST FIPS compliance requirements may also prefer NIST P-256 as it is specified in FIPS 186-5. Both choices are fully supported on login-plus.discoverer.bg. Where the authenticator supports both algorithms, sk-ssh-ed25519 is preferred as it has a simpler implementation and is less susceptible to misuse of the signing API (Ed25519 uses a deterministic nonce, whereas ECDSA requires a high-quality random nonce for each signature).

Types of authenticator backing SK keys

Hardware security keys

Hardware security keys — such as the YubiKey 5 series, Google Titan, and Nitrokey FIDO2 — are dedicated USB (or NFC) devices whose sole purpose is to perform FIDO2 operations. The private key material is generated and stored within the device’s secure element and cannot be extracted under any circumstances.

Key properties of hardware security keys relevant to SSH authentication:

The device must be physically connected (USB or NFC) to the client host at the time of each authentication.
Every signing operation requires a capacitive touch on the device (user-presence verification). Some devices additionally support a PIN (user-verification).
The private key cannot be backed up or exported. Loss or physical destruction of the device results in permanent loss of the associated private key.
Hardware security keys are entirely independent of the operating system’s secure enclave and do not rely on platform-specific key storage.

Important

Always procure at least two hardware security keys and register both public keys with your account on login-plus.discoverer.bg. Store the backup device in a physically separate location. Failure to maintain a registered backup key may result in permanent loss of access should the primary device be lost, stolen, or damaged.

Platform and software authenticators

Platform authenticators are FIDO2 implementations integrated into the operating system or a software application, rather than residing on dedicated hardware. The private key material is generated and stored within the platform’s secure enclave or Trusted Execution Environment (TEE), if available, or in software-protected storage otherwise.

Android platform authenticator

Android 9 and later include a built-in FIDO2 platform authenticator accessible through the Android Keystore system. On devices equipped with a hardware-backed TEE or a dedicated Secure Element, private key material is stored in hardware-isolated memory inaccessible to the Android operating system itself.

Key properties specific to Android authenticators:

The Android device must be within Bluetooth Low Energy range of the client host during authentication. The FIDO2 hybrid transport (caBLE) is used to relay the signing request from the SSH client to the Android authenticator via the libfido2 library.
The user must unlock the Android device and approve the signing request — typically via fingerprint, face recognition, or device PIN — before the signature is returned.
Key backup behaviour depends on the device and account configuration. Google Password Manager may synchronise FIDO2 passkeys (resident keys) across Android devices signed into the same Google account. Non-resident SK key handles stored on the client filesystem are not automatically backed up and must be preserved manually.
A factory reset, remote wipe, or removal of the Google account from the device will destroy the private key material, regardless of whether cloud synchronisation was enabled.
Using the Android authenticator from a different client host requires re-pairing via Bluetooth and completing the caBLE hybrid flow each time. This process is reliable only with OpenSSH clients built against libfido2 with caBLE support enabled (verify with pkg-config --modversion libfido2).

Warning

Android software tokens are not equivalent to hardware security keys in terms of loss guarantees. A hardware security key that is physically lost can be confirmed as inoperative. An Android device may be remotely wiped, factory-reset during repair, or have its key material silently destroyed following a failed Google account recovery procedure. Users relying on Android authenticators must register a second, independent backup key with their account.

macOS and iOS platform authenticator

macOS 13 (Ventura) and later, and iOS 16 and later, include a FIDO2 platform authenticator backed by the Secure Enclave. Keys may be synchronised across Apple devices via iCloud Keychain if the resident key flag is used during generation.

The connectivity and user-presence requirements are analogous to those described for the Android platform authenticator above. caBLE transport is used when the authenticator resides on an iOS device and the SSH client runs on a separate macOS or Linux host.

Prerequisites

Required software components

The following software components must be present on the client host before an SK key can be generated or used:

OpenSSH 8.2 or later — earlier releases do not include SK key support.
libfido2 1.5.0 or later — the FIDO2 client library used by OpenSSH to communicate with the authenticator. Verify the installed version with pkg-config --modversion libfido2.
udev rules (Linux only) — required to grant non-root processes access to the USB HID interface exposed by hardware security keys.

Linux systems

# RHEL / Rocky Linux / Fedora
sudo dnf install libfido2 libfido2-devel openssh-clients

# Debian / Ubuntu
sudo apt-get install libfido2-1 libfido2-dev fido2-tools openssh-client

# Verify udev rules for hardware security keys are installed
# (on most distributions this is handled automatically by the libfido2 package)
ls /etc/udev/rules.d/ | grep -i fido

# Reload udev rules without rebooting
sudo udevadm control --reload-rules && sudo udevadm trigger

macOS systems

# Using Homebrew
brew install libfido2 openssh

Generating an SK key pair

Resident versus non-resident keys

FIDO2 defines two storage models for private key material, which have distinct implications for SSH use:

Property	Non-resident key (default)	Resident key (`-O resident`)
Key handle storage	On the client filesystem (`~/.ssh/id_ed25519_sk`, etc.)	On the authenticator itself
Authenticator storage	Minimal — only a key wrapping secret is retained by the device	Full key material stored in authenticator memory (consumes a slot)
Loss of key handle file	Loss of handle = loss of access, even if authenticator is intact	Key can be recovered from the authenticator using `ssh-keygen -K`
Authenticator slot consumption	None consumed	Consumes one resident key slot (hardware devices have finite capacity)
Suitable for most users	Yes	Only when portability across client hosts is a firm requirement

Important

Preserve the key handle file. For non-resident keys, the file created in ~/.ssh/ (e.g., id_ed25519_sk) is required for every authentication operation. It does not contain the private key, but without it the authenticator cannot reconstruct the signing context. Back up this file to secure, offline storage.

Key generation with a hardware security key

Ensure the hardware security key is plugged into a USB port before executing the following commands.

To generate an sk-ssh-ed25519 key pair (preferred where the authenticator supports it):

ssh-keygen -t ed25519-sk -C "your-username@login-plus.discoverer.bg"

To generate an sk-ecdsa-sha2-nistp256 key pair (use when the authenticator does not support Ed25519, or when FIPS 186-5 / NIST P-256 compliance is required):

ssh-keygen -t ecdsa-sk -C "your-username@login-plus.discoverer.bg"

Both commands will prompt for a passphrase to protect the key handle file, and the hardware security key will request a capacitive touch to confirm key generation. The generated files follow the naming convention:

~/.ssh/id_ed25519_sk or ~/.ssh/id_ecdsa_sk — the key handle file (not a private key; must be kept secure)
~/.ssh/id_ed25519_sk.pub or ~/.ssh/id_ecdsa_sk.pub — the public key to be registered with your account

To generate a resident key on the authenticator, append the -O resident flag:

ssh-keygen -t ed25519-sk -O resident -C "your-username@login-plus.discoverer.bg"

Warning

Hardware security keys have a finite number of resident key slots (typically 25 slots on YubiKey 5 series devices). Generating more resident keys than the device supports will result in an error. Prefer non-resident keys unless cross-host portability is a firm requirement.

Key generation with a platform or software authenticator

When the authenticator is an Android or iOS device, the FIDO2 hybrid transport (caBLE) is used. The client host and the mobile device must both have Bluetooth enabled. The process is mediated by the browser or the operating system on the mobile device.

# Initiate key generation; OpenSSH will display a QR code or invoke
# the caBLE pairing procedure depending on the libfido2 version installed
ssh-keygen -t ed25519-sk -C "your-username@login-plus.discoverer.bg"

On the Android or iOS device:

Open the device camera or the browser when prompted by the caBLE pairing flow.
Scan the QR code displayed on the client terminal (if applicable to the installed libfido2 version).
Confirm the key generation request using the device biometric or PIN.

Note

The caBLE hybrid transport requires libfido2 to be compiled with caBLE support. Verify this with fido2-token -L whilst the mobile device is nearby and Bluetooth is active on both hosts. Not all distribution packages enable caBLE support at compile time. If the command produces no output despite a nearby mobile authenticator, obtain a libfido2 build with caBLE support from the vendor or compile from source.

Registering the public key

Once the key pair has been generated, extract the public key from the .pub file and submit it for registration with your login-plus.discoverer.bg account:

cat ~/.ssh/id_ed25519_sk.pub

The output will resemble the following:

sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc...AAAA your-username@login-plus.discoverer.bg

Submit this string to the support team following the instructions provided in Getting help. Do not submit the key handle file itself.

SSH client-side configuration

Create or modify ~/.ssh/config to instruct the SSH client to present the SK key when connecting to login-plus.discoverer.bg:

Host login-plus.discoverer.bg
    HostName login-plus.discoverer.bg
    Port 22
    User your-discoverer-plus-username
    IdentityFile ~/.ssh/id_ed25519_sk
    IdentitiesOnly yes

The IdentitiesOnly yes directive prevents the SSH client from offering keys loaded into the SSH agent that are not explicitly listed in IdentityFile. This avoids unnecessary failed authentication attempts that may trigger the server-side rate limiter.

Important

Do not add SK key handles to the SSH agent with ssh-add. SK keys do not benefit from agent forwarding in the traditional sense — the authenticator must still be present and reachable at signing time. Adding the handle to the agent does not remove this requirement and may cause confusion when the agent attempts to use the handle without the authenticator being available.

Operational constraints and limitations

Authenticator availability

The authenticator must be reachable for the full duration of the SSH handshake. The following scenarios will cause authentication to fail:

The hardware security key is unplugged or the USB port is in a suspended power state.
The Android or iOS device is out of Bluetooth range, has Bluetooth disabled, or the screen is locked and the user does not respond to the signing prompt within the timeout window (typically 30 seconds).
libfido2 is not installed or is an incompatible version.
The user-presence gesture (touch or biometric) is not performed within the timeout window.

Failed authentication attempts due to authenticator unavailability are indistinguishable from failed key-based authentication attempts at the server level and count towards the rate limiter threshold.

Unsuitability for automated and non-interactive workflows

SK keys must not be used in any of the following contexts:

Job submission scripts executed by the workload manager (SLURM, PBS, etc.)
Automated scp, rsync, or sftp data transfers
SSH tunnels established by background daemons or monitoring agents
Configuration management tools (Ansible, Puppet, Chef) executing over SSH
CI/CD pipelines

For all such use cases, generate and register a traditional ed25519 key pair without the -sk suffix. Refer to SSH Key Generation for instructions.

Backup and recovery

The consequences of losing access to the authenticator depend on the key type:

Scenario	Hardware security key	Android / iOS platform authenticator
Device lost or destroyed	Private key permanently lost; access via that key is irrecoverable	Private key permanently lost unless resident key was synchronised via Google / iCloud account
Key handle file lost (non-resident key)	Non-resident key: access irrecoverable. Resident key: recoverable via `ssh-keygen -K` if device is intact	Non-resident key: access irrecoverable. Resident key: recoverable via `ssh-keygen -K` if device is intact
Factory reset / remote wipe	Not applicable	Private key destroyed; access irrecoverable unless synchronised
Google / iCloud account recovery	Not applicable	Synchronised resident keys may be destroyed or rendered inaccessible

To recover a resident key from an intact authenticator:

# Download all resident keys from the authenticator to the current directory
ssh-keygen -K

This command writes files named id_ed25519_sk_rk and id_ed25519_sk_rk.pub (or the ECDSA equivalents) to the current working directory. The authenticator will require a PIN and a touch gesture to authorise the operation.

Warning

Register a second, independent key — a traditional ed25519 key pair or a second SK key backed by a separate authenticator — with your account on login-plus.discoverer.bg. This ensures continued access in the event of authenticator loss or failure.

Troubleshooting

Common issues

libfido2 not found or incompatible version

# Check installed version (must be 1.5.0 or later)
pkg-config --modversion libfido2

# List FIDO2 authenticators visible to libfido2
fido2-token -L

Key generation fails with “no authenticators found”

# Verify udev rules are installed (Linux)
ls /etc/udev/rules.d/ | grep -i fido

# Check whether the hardware security key is detected by the kernel
lsusb | grep -i yubikey    # replace with the appropriate vendor name

# Reload udev rules
sudo udevadm control --reload-rules && sudo udevadm trigger

Authentication fails with sign_and_send_pubkey: signing failed: agent refused operation

This error typically indicates one of the following:
- The authenticator is not present or not reachable (check USB connection or Bluetooth state).
- The key handle file does not correspond to the key registered on the server.
- The user did not perform the required touch or biometric gesture within the timeout window.
To diagnose further, enable verbose SSH output:
```
ssh -vvv your-username@login-plus.discoverer.bg
```
caBLE hybrid transport not working with Android authenticator
```
# Verify Bluetooth is active on the client host (Linux)
bluetoothctl show | grep "Powered"

# Check whether libfido2 was compiled with caBLE support
fido2-token -L    # should enumerate the mobile device when nearby
```
If fido2-token -L does not enumerate the Android device despite Bluetooth being active on both hosts, the installed libfido2 package was likely compiled without caBLE support. Install a caBLE-enabled build from the distribution’s backports repository or compile from source following the libfido2 build instructions.
Rate limiter blocks IP address during authentication

If the SSH server blocks the client IP address due to repeated failed attempts caused by authenticator unavailability or timeout, wait for the lockout period to expire before retrying. Use ssh -vvv to verify which key the client is presenting and ensure the authenticator is available before initiating the connection.

Resident key slot exhaustion on hardware security key

# List resident keys stored on the device (requires device PIN)
fido2-token -L    # identify the device path first
fido2-token -P /dev/hidraw0    # replace with the correct device path

Delete unused resident keys using fido2-token -D before generating new ones.

Getting help

For technical support and implementation assistance, contact our support team. See Getting help.