A FIDO backed SSH key, type ed25519-sk or ecdsa-sk, keeps its real private key on a hardware authenticator that cannot export it. The file on disk is only a handle. Without the token attached, the file is useless, which makes laptop theft far less damaging for your SSH access.
How the key is built
The OpenSSH ssh-keygen manual describes two parts. One is a key handle stored in the private key file on disk. The other is a per device private key that stays on the authenticator and cannot be exported. The key works only while the authenticator is attached, and authenticators generally require a touch or tap to authorise operations.
The -b size option is ignored for these types because their lengths are fixed.
Creating one
GitHub's guide shows the command, with the token plugged in:
ssh-keygen -t ed25519-sk -C "your_email@example.com"
If you see an invalid format or feature not supported error, your token does not support Ed25519, so use the other type:
ssh-keygen -t ecdsa-sk -C "your_email@example.com"
Touch the token when it blinks, accept the default path, and upload the public file as you would any SSH key. GitHub says the token must be connected each time you authenticate, and that this needs OpenSSH 8.2 or later. On macOS and Linux you may need a newer SSH client than the one that ships by default.
What it fixes and what it does not
Fixes
- Stolen key files. Copying
~/.sshgets an attacker a handle, not a usable key. - Silent use by malware. Each signature needs a physical touch, unless the key was created without that requirement.
Does not fix
- Loss of the token itself, so register two tokens and keep one safely stored.
- A user who touches the token on a prompt they did not start.
- Compromise of the server side. It protects the login, not what you do after.
Options you will see
verify-requiredasks for user verification on each signature. The manual says not all authenticators support it and that PIN is the only verification method currently supported.no-touch-requiredcreates a key that needs no touch. The manual notes sshd refuses such signatures by default unless an authorized_keys option overrides it. Avoid it unless you have a specific reason.
Both can be changed later with the -p option.
When to choose this
Pick hardware keys for production access, for admins, and for anyone holding signing or deploy privileges. For the rest, a passphrase protected software key is a fair baseline. For the resident key question, see resident or non resident FIDO SSH keys. For account login rather than SSH, read about passkeys.
Quick check
Can I back up a security key SSH key to a second token?
You cannot copy the private part off the token. Create a separate key on a second token and register both public keys.
Sources
Last reviewed: 19 October 2026.
