$ ssh-keygen -t ecdsa-sk -f ~/.ssh/id_ecdsa_sk
-t ecdsa-skspecifies the key type to generate. Alternatively, you can generate Ed25519 keys using-t ed25519-sk.-f ~/.ssh/id_ecdsa_skspecify the output path for the newly generated key.
You can provide a passphrase for your key if you would like to do so. Unlike normal ssh keys, the private key is not that sensitive, as it is useless without the physical security key itself.
ed25519-sk vs ecdsa-sk
Newer YubiKeys (firmware >=5.2.3) and some other FIDO2 keys, support Ed25519 keys. Ed25519 have some advantages over the common ECDSA keys in several aspects:
- Ed25519 is based on the Curve25519 vs NIST P-256 used for
ecdsa-sk. Curve25519 is generally regarded as faster and safer than NIST P-256, see SafeCurves. Furthermore, the underlying signature algorithm (Schnorr vs DSA) is slightly faster for Ed25519 - EdDSA in general, and Ed25519 in particular, uses deterministic nonce versus random nonce used by ECDSA. This means that ECDSA is prune to catastrophic entropy failure (see the famous fail0verflow PS3 hack as an example). Assuming your key has access to high entropy randomness, that shouldn’t be a problem. However, that assumption might turn out false, like in the case of the reduced initial randomness in the Yubikey FIPS Series.
In the bottom line, if you have access to a key that supports ed25519-sk then it’s preferable to use it. If you don’t, that’s not something to worry about to much. There are probably weaker points in your threat model anyway.
If your FIDO2 key doesn’t support ed25519-sk you will get the following error when trying to generate a key:
Key enrollment failed: requested feature not supported
Moving keys to a new computer
If you want to use the keys on a new computer, you will have to copy over the private key file that you generated. That will normally be ~/.ssh/id_ecdsa_sk or ~/.ssh/id_ed25519_sk, depending on the type of key you generated.
Alternatively, you can generate resident keys which are completely stored on the YubiKey. To generate resident keys, append the -O resident to your ssh-keygen command. Example:
$ ssh-keygen -t ecdsa-sk -O resident
To import the keys to a new device, use the -K option:
$ ssh-keygen -K
This will download all the keys (public and private) from the YubiKey to the current directory. There is no need to manually transfer any key files.
YubiKey Series 5 devices can hold up to 25 resident keys.
Do you know, that with these keys, SSH can be a full PGP replacement for signing files? No need in overblown PGP! Anybody can try to make, like that (for more do read the app’s manual): ssh-keygen -Y sign -n “file” -f /.ssh/id_ed25519_sk < “${file_to_sign}” > “${file_to_sign}.asc”
Sorry, it seems WordPress ate certain punctuation. :/
Append the some flag. I got a chuckle out of that. I’m assuming that is leftover placeholder text. Should probably be updated to:
append the -O resident flag to your ssh-keygen command.
Thanks, fixed.
Thank you Guy for posting this, it was hard to find this clearly anywhere else.
Also thanks to OhWell for that excellent suggestion above.