Notes

Home About Contact Archive

---

GitHub LinkedIn Twitter

OpenSSH - Configuring FIDO2 Resident Keys

Configuring a YubiKey for ssh resident keys

Table of Contents

1. The Setup
2. Creating keys
   1. Generating the non-resident handle
   2. Generating the resident handle
3. Using the token
   1. Resident
      1. Transient usage with ssh-add
      2. Permanent usage with ssh-agent
   2. Non-resident

The Setup

If you haven’t heard, OpenSSH recently ([2020-02-14 Fri]) gained support for FIDO2/U2F hardware authenticators like the YubiKey 5!

This allows one to log into remote hosts with the touch of a button and it makes me feel like I am living in the future!

Some of these hardware tokens even support multiple slots, allowing one to have multiple keys!

On top of all that, the tokens can do “resident” and “non-resident” keys. “Resident” means that the key is effectively retrievable from the token (it doesn’t actually get the key - it’s a handle that lets one use the hardware key on the device).

This got me thinking about how I could use a single token (with two keys) to access the various machines I use.

In my use case, I have two types of machines I want to connect to:

• greater security: machines I want to grant access to from a very select number of devices.

The greater key will require me to copy the “key handle” to the machines I want to use it from.

• lesser security: machines I want to access from devices that may not be as secure.

The lesser key will be “resident” to the YubiKey. This means it can be downloaded from the YubiKey itself. Because of this, it should be trusted a bit less.

Creating keys

When creating FIDO keys (really they are key handles) one needs to explicitly tell the tool being used that it needs to pick the next slot. Otherwise generating the second key will clobber the first!

Generating the non-resident handle

greater will require me to send the ~/.ssh/ed25519_sk_greater handle to the various hosts I want to use it from.

We will be using ssh-keygen to create our resident key.

ssh-keygen -t ed25519-sk -Oapplication=ssh:greater -f ~/.ssh/ed25519_sk_greater

Generating the resident handle

Because resident keys allow for the handle to be downloaded from the token, I have changed the PIN on my token. The PIN is the only defense against a stolen key. Note: the PIN can be a full passphrase!

Again via ssh-keygen.

ssh-keygen -t ed25519-sk -Oresident -Oapplication=ssh:lesser -f ~/.ssh/ed25519_sk_lesser

Using the token

Resident

The resident key can be used by adding it to ssh-agent or by downloading the handle / public key using ssh-keygen:

Transient usage with ssh-add

ssh-add -K

This will prompt for the PIN (which should be set as it’s the only defense against a stolen key!)

No handle files will be placed on the machine you run this on. Handy for machines you want to ssh from but don’t fully trust.

Permanent usage with ssh-agent

ssh-keygen -K

This will also prompt for the PIN, however, it will create the private key handle and corresponding public key and place them in $CWD.

Non-resident

The non-resident key will only work from hosts that have the handle (in our case ~/.ssh/ed25519_sk_greater). As such, the handle must be copied to the machines you want to allow access from.

Once the handle is in place, you can specify it’s usage in ~/.ssh/config:

Host secretsauce
    IdentityFile ~/.ssh/ed25519_sk_greater

---

Made by qbit. Subscribe via RSS / Atom | Generated using boring and these files. proof.