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 <#introduction>`__ - `What SK keys are <#what-sk-keys-are>`__ - `How SK keys differ from traditional SSH key pairs <#how-sk-keys-differ-from-traditional-ssh-key-pairs>`__ - `Operational considerations for SK key users <#operational-considerations-for-sk-key-users>`__ - `Effective security level of SK key types <#effective-security-level-of-sk-key-types>`__ - `Types of authenticator backing SK keys <#types-of-authenticator-backing-sk-keys>`__ - `Hardware security keys <#hardware-security-keys>`__ - `Platform and software authenticators <#platform-and-software-authenticators>`__ - `Android platform authenticator <#android-platform-authenticator>`__ - `macOS and iOS platform authenticator <#macos-and-ios-platform-authenticator>`__ - `Prerequisites <#prerequisites>`__ - `Required software components <#required-software-components>`__ - `Linux systems <#linux-systems>`__ - `macOS systems <#macos-systems>`__ - `Generating an SK key pair <#generating-an-sk-key-pair>`__ - `Resident versus non-resident keys <#resident-versus-non-resident-keys>`__ - `Key generation with a hardware security key <#key-generation-with-a-hardware-security-key>`__ - `Key generation with a platform or software authenticator <#key-generation-with-a-platform-or-software-authenticator>`__ - `Registering the public key <#registering-the-public-key>`__ - `SSH client-side configuration <#ssh-client-side-configuration>`__ - `Operational constraints and limitations <#operational-constraints-and-limitations>`__ - `Authenticator availability <#authenticator-availability>`__ - `Unsuitability for automated and non-interactive workflows <#unsuitability-for-automated-and-non-interactive-workflows>`__ - `Backup and recovery <#backup-and-recovery>`__ - `Troubleshooting <#troubleshooting>`__ - `Common issues <#common-issues>`__ - `Getting help <#getting-help>`__ Introduction ------------ .. _what-sk-keys-are: 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 <#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: How SK keys differ from traditional SSH key pairs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +---------------------------+------------------------------------------+------------------------------------------+ | Aspect | Traditional SSH key pair | SK-backed SSH key pair | | | (``ed25519``, ``ecdsa``, ``rsa``) | (``sk-ssh-ed25519``, | | | | ``sk-ecdsa-sha2-nistp256``) | +===========================+==========================================+==========================================+ | Private key location | File on the local filesystem | Protected memory of the FIDO2 | | | (``~/.ssh/id_*``) | 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 | Yes | No | | automation | | | +---------------------------+------------------------------------------+------------------------------------------+ | Compromise risk on | High — key file accessible to malware | Low — private key protected even on | | compromised host | or unauthorised users | a compromised host | +---------------------------+------------------------------------------+------------------------------------------+ .. _operational-considerations-for-sk-key-users: 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: 1. Middleware dependency: ``libfido2`` version 1.5.0 or later must be installed on the client host. Older distributions ship with incompatible versions. 2. 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. 3. 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. 4. 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: 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\ :sup:`128` 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 ~~~~~~~~~~~~~~~~~~~~~~ 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 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 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 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: 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: Linux systems ^^^^^^^^^^^^^ .. code:: bash # 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: macOS systems ^^^^^^^^^^^^^ .. code:: bash # Using Homebrew brew install libfido2 openssh Generating an SK key pair ------------------------- .. _resident-versus-non-resident-keys: 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 | On the authenticator itself | | | (``~/.ssh/id_ed25519_sk``, etc.) | | +---------------------------+------------------------------------------+------------------------------------------+ | Authenticator storage | Minimal — only a key wrapping secret | Full key material stored in | | | is retained by the device | authenticator memory (consumes a slot) | +---------------------------+------------------------------------------+------------------------------------------+ | Loss of key handle file | Loss of handle = loss of access, | Key can be recovered from the | | | even if authenticator is intact | authenticator using ``ssh-keygen -K`` | +---------------------------+------------------------------------------+------------------------------------------+ | Authenticator slot | None consumed | Consumes one resident key slot | | consumption | | (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: 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): .. code:: bash 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): .. code:: bash 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: .. code:: bash 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: 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. .. code:: bash # 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: 1. Open the device camera or the browser when prompted by the caBLE pairing flow. 2. Scan the QR code displayed on the client terminal (if applicable to the installed ``libfido2`` version). 3. 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: .. code:: bash cat ~/.ssh/id_ed25519_sk.pub The output will resemble the following: .. code:: bash 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 :doc:`help`. Do not submit the key handle file itself. SSH client-side configuration ----------------------------- .. _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``: .. code:: bash 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: 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: 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 :doc:`ssh_key_generation` for instructions. .. _backup-and-recovery: 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; | Private key permanently lost unless | | | access via that key is irrecoverable | resident key was synchronised via | | | | Google / iCloud account | +---------------------------+------------------------------------------+------------------------------------------+ | Key handle file lost | Non-resident key: access irrecoverable. | Non-resident key: access irrecoverable. | | (non-resident key) | Resident key: recoverable via | Resident key: recoverable via | | | ``ssh-keygen -K`` if device is intact | ``ssh-keygen -K`` if device is intact | +---------------------------+------------------------------------------+------------------------------------------+ | Factory reset / | Not applicable | Private key destroyed; access | | remote wipe | | irrecoverable unless synchronised | +---------------------------+------------------------------------------+------------------------------------------+ | Google / iCloud | Not applicable | Synchronised resident keys may be | | account recovery | | destroyed or rendered inaccessible | +---------------------------+------------------------------------------+------------------------------------------+ To recover a resident key from an intact authenticator: .. code:: bash # 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 ~~~~~~~~~~~~~ 1. ``libfido2`` not found or incompatible version .. code:: bash # Check installed version (must be 1.5.0 or later) pkg-config --modversion libfido2 # List FIDO2 authenticators visible to libfido2 fido2-token -L 2. Key generation fails with "no authenticators found" .. code:: bash # 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 3. 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: .. code:: bash ssh -vvv your-username@login-plus.discoverer.bg 4. caBLE hybrid transport not working with Android authenticator .. code:: bash # 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 `__. 5. 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. 6. Resident key slot exhaustion on hardware security key .. code:: bash # 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 :doc:`help`.