In a bout of attempting to improve my operational security, I decided to review my current pracitices and see which areas I could improve. While I already use SSH keys for auth, having a file that is essentially a password to all my servers is a bit of a security risk if it ever is compromised. I already use my SoloKey for 2FA on various websites, so why not for SSH too? This way, even if someone gets my private key file, they can’t access my servers without physically having my SoloKey. Still a risk (see the XKCD comic about a $5 wrench), but less so.

Editor’s Note: While MFA by using a physical key is a great, you really should look into using SSH Certificates as they are time scoped, and depending on how you have them set up, have automatic rotation. Among other benefits, this is a great way to ensure that even if a key is unknowingly compromised, it can’t be used for long.

Also, this same process could be used for other physical keys like YubiKeys, but I have several SoloKeys V2 (cheaper and open-souce) so that is what I used.

Diving right into it

According to the docs, all that is required should only be running ssh-keygen -t ed25519-sk and then touching the SoloKey when prompted. However, when testing this, I was on macOS devices and ran into an issue where the SSH version that ships with macOS doesn’t support these types of keys. So, I had to install a newer version of OpenSSH with:

brew install openssh libfido2

After installation, you can check that you have the right version:

ssh -V

You should see OpenSSH_8.9 or later, which supports the FIDO2 keys. If you don’t, then you may need to update your $PATH environment variable to point to the Homebrew version of SSH.

Creating a key tied to your SoloKey

Now that I have the right version of SSH installed, I can finally create the key:

ssh-keygen -t ed25519-sk -f ~/.ssh/id_ed25519_sk

You’ll be asked for a passphrase (recommended), and be prompted to touch your SoloKey to confirm. Once done, you’ll have two new files:

  • ~/.ssh/id_ed25519_sk - your private key
  • ~/.ssh/id_ed25519_sk.pub - your public key

Making it convenient

For convenience, I added the key to my SSH agent:

ssh-add ~/.ssh/id_ed25519_sk

If you don’t use the SSH agent, you could instead add the key to your SSH configuration file

vi ~/.ssh/config

# Use the security key for all connections
Host *
    IdentityFile ~/.ssh/id_ed25519_sk

Setting up the server side

Similarily to how you would add a regular SSH key, you can add the public key to your server:

cat ~/.ssh/id_ed25519_sk.pub | pbcopy
ssh user@remote-server "vi ~/.ssh/authorized_keys" # Paste the public key and save

Just like with your local machine, you’ll need to make sure the remote server also supports the new key type. You can check this by running:

ssh user@remote-server "ssh -V"

The moment of truth

Now try connecting:

ssh user@remote-server

If everything’s set up correctly, you’ll be prompted to touch your SoloKey to authenticate.

Wrapping up

Setting this up took a bit of tinkering (especially figuring out about macOS and its older SSH version), but the extra security is worth it. You can also use this key for other services, like your Gitea instance.

If you are on a mac, you could also look into the tool Secretive, which allows you to store your SSH keys in the Secure Enclave of your Mac and integrate with the native Touch ID.