An ed25519-sk SSH key is an Ed25519 key whose signing operation happens inside a FIDO2 security key. You create it with ssh-keygen -t ed25519-sk, it requires a touch on the key at every login, and it only works when both client and server run OpenSSH 8.2 or later, released in February 2020.
How an OpenSSH ed25519-sk key differs from a regular Ed25519 key
OpenSSH has supported Ed25519 since version 6.5 (January 2014) and the FIDO2 variant ed25519-sk since 8.2 (February 2020). The difference is where the secret lives. With a classic Ed25519 key, ~/.ssh/id_ed25519 is the private key: anyone who copies it and knows the passphrase can log in to your servers.
With ed25519-sk, the signature is computed inside the hardware key. The file ssh-keygen writes to disk, id_ed25519_sk, is a key handle that is useless without the physical device. Every authentication also requires user presence: a touch on the key. Stealing the laptop or the file is no longer enough.
What stays the same: the public key goes into authorized_keys as usual, now with the type [email protected], and the expected permissions are unchanged: ~/.ssh at 700, authorized_keys and key files at 600.
How to generate an ed25519-sk key with ssh-keygen, step by step
The base command is ssh-keygen -t ed25519-sk with the FIDO2 key plugged in; ssh-keygen asks you to touch it during generation. Every -O option is covered in the official ssh-keygen manual page.
# Non-resident key: the handle stays in ~/.ssh/id_ed25519_sk
ssh-keygen -t ed25519-sk -C "work-key"
# Resident key, PIN required, with its own label
ssh-keygen -t ed25519-sk -O resident -O verify-required -O application=ssh:production
# Install the public key on the server
ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub user@server
# On another machine: pull the resident keys off the token
ssh-keygen -K
# Or load them straight into ssh-agent
ssh-add -KThe options you will actually use:
- -O resident: stores the credential on the token so you can recover it on another machine.
- -O verify-required: on top of the touch, requires the token PIN for every signature.
- -O application=ssh:name: tells several resident keys on the same token apart; the value must start with
ssh:. - -O no-touch-required: drops the touch, but the server only accepts it if the
authorized_keysline carries theno-touch-requiredoption.
-O resident on ed25519-sk: the key travels inside the FIDO2 token
With -O resident, the credential is stored on the FIDO2 token itself, not only in the local file. On a new machine, plug in the token and run ssh-keygen -K, which writes the files to the current directory, or ssh-add -K to load it into the agent without touching disk.
The upside is that you no longer depend on each machine's file. The risk mirrors it: whoever holds the token can extract the handle, so protect it with a PIN and pair -O resident with -O verify-required. Without -O resident, losing id_ed25519_sk means losing access from that machine even if you still have the token. Tokens that only implement U2F cannot store resident credentials.
Which servers accept ed25519-sk keys: OpenSSH 8.2 or later
A server accepts ed25519-sk keys if its sshd is OpenSSH 8.2 or later. The server needs no token attached; it only has to understand the [email protected] key type. Check before you retire your current key:
# OpenSSH version installed on the server
ssh -V
# Public key algorithms sshd actually accepts
sudo sshd -T | grep -i pubkeyaccepted
# ~/.ssh/authorized_keys line that also requires a PIN
verify-required [email protected] AAAA... work-keyIf [email protected] shows up in the sshd -T output, the key will work. To require a PIN for every user, add PubkeyAuthOptions verify-required to sshd_config. A server that predates 8.2 also predates 8.8, the release that disabled ssh-rsa SHA-1 signatures by default, so it is overdue for an upgrade anyway. The OpenSSH release notes page lists what shipped in each version.
ed25519-sk keys versus Ed25519 keys on a phone: comparison table
On a desktop, ed25519-sk works with any OpenSSH 8.2 or later and a plugged-in token; on iOS and Android it depends on the client implementing FIDO2 and on how the token connects to the phone. The usual mobile alternative is an Ed25519 key generated on the device itself.
| What is compared | ed25519-sk on desktop | Ed25519 in the phone's secure storage |
|---|---|---|
| Where the secret lives | Inside the FIDO2 token | In iOS or Android secure storage |
| What you need to log in | Token plugged in and a touch | The phone that holds the key |
| Minimum OpenSSH on the server | 8.2 (February 2020) | 6.5 (January 2014) |
| If someone copies the file | Useless without the physical token | In termi1 the private key never leaves the device |
| Using the key on another machine | With -O resident and ssh-keygen -K | Generate a separate key per device |
termi1, the SSH terminal for iOS and Android, follows the second model: it generates the key on the phone, keeps it in the system's secure storage, and never sends the private key to termi1's servers; the AI does not open the session or receive keys either. A sensible setup is one ed25519-sk key for the laptop plus one key per phone in authorized_keys, so you revoke only the one you lose. With Mosh, authentication only happens on the initial SSH connection that starts mosh-server; switching from Wi-Fi to mobile data does not trigger it again, and tmux keeps whatever you left running.
4 mistakes when setting up ed25519-sk keys with OpenSSH
- Server older than OpenSSH 8.2. sshd does not recognise the key type and rejects it; keep your old key until you have checked the version.
- Only one FIDO2 token registered. If it is lost or breaks, so is your access. Register two tokens, or a token plus a backup key.
- Deleting id_ed25519_sk for a non-resident key. Without
-O residentit cannot be recovered from the token; back it up or create the key as resident. - Closing the old session before testing. Open a second connection with
ssh -i ~/.ssh/id_ed25519_sk user@serverbefore editingsshd_config.
Frequently asked questions
Which OpenSSH version do I need for ed25519-sk keys?
ed25519-sk keys require OpenSSH 8.2 or later, released in February 2020, on both the client that creates and uses the key and the server that verifies it. Check the installed version with ssh -V and the algorithms the server accepts with sshd -T.
What does -O resident do in ssh-keygen?
The -O resident option in ssh-keygen stores the FIDO2 credential on the security key itself, so it can be recovered on another machine with ssh-keygen -K or loaded into the agent with ssh-add -K. It is best combined with a token PIN and -O verify-required.
Can someone steal an ed25519-sk key by copying the file?
An ed25519-sk key cannot be used by copying the id_ed25519_sk file alone, because that file is only a key handle and the signature is computed inside the FIDO2 token. Logging in requires the physical device and, by default, a touch at every authentication.
Can I use FIDO2 SSH keys from a phone?
Using FIDO2 SSH keys on iOS or Android depends on the mobile client implementing ed25519-sk and on how the token connects to the phone. The common alternative is an Ed25519 key generated on the device and kept in its secure storage, which is how termi1 works.