GPG for SSH is not great
The old way of using security keys with SSH meant going through GPG. It worked, kind of, but it came with real limitations. You were pretty much stuck using the same SSH key across all your machines, since GPG doesn’t let you easily manage multiple keys tied to one device. Plus you had to mess with GPG agent configuration on every client. Not ideal if you just want things to work.
Why this is better
- Unlimited SSH keys — FIDO2/U2F doesn’t have GPG’s limitations. You can generate as many SSH keys as you want, all tied to one security key. That means a unique key per machine, per server, whatever you need.
- No client config needed — Unlike GPG where you had to swap out ssh-agent, this just works. As long as your SSH client is up to date, you’re good.
- Stronger security — An attacker now needs three things: your private key file, your physical security key, and optionally a password. That’s proper multi-factor authentication for SSH.
OpenSSH 8.2 added native FIDO/U2F support, which turns what used to be a pain into something dead simple.
Generate Your New Keys
SSH keys ending in -sk use your FIDO2/U2F device as a second factor. We’ll generate ed25519-sk keys based on the ed25519 elliptic curve.
First, make sure your SSH is version 8.2 or newer:
ssh -VPlug in your security key and generate the keypair:
ssh-keygen -t ed25519-sk -f <Keyfile location>Follow the prompts. You’ll enter your security key PIN and optionally set a password on the key itself for even more security. You might need to tap the key too.
That’s it. Your new keys work exactly like any other SSH key, except now you’ll be asked for your security key every time you use them.
Deploy to Your Server
Add the public key (the .pub file) to the user’s authorized_keys inside $HOME/.ssh/ on the server.
One thing: the server needs OpenSSH 8.2 or newer too, otherwise these keys won’t be recognized.