Using a hardware key for better security

WUR employees can get a Yubikey hardware key for free at the servicedesk in Forum.

With that key, you can implement multifactor authentication for your SSH connections.

Depending on you choices and setup, you can make it very secure, so that without the key, pin and password your SSH key won't be able to be used.

The steps below are adaptations of https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html

Different levels of security/annoyance

There are different levels of security you can apply, each being more secure, but also introducing an extra step before you have an active session.

There a three "interactions" that can be used:

1. Enforce/use a password to unlock your SSH key
2. Enforce/use a PIN to unlock the hardware key
3. Enforce/use touching the hardware key to get access

This then leads to the following 4 scenarios:

1. Use SSH key password, pin and touch for each new SSH session (no SSH agent)
2. Use pin and touch for each new SSH session (use SSH agent for password)
3. Use touch for each new SSH session (use SSH agent for password, but no PIN enforcement in key)
4. Use SSH key password and touch for first SSH session (pass in SSH agent, no PIN and touch enforcement in key)

The last one is the least intrusive, and as an attacker would need physical access to your device to circumvent your security, this is probably fine for most people.

This is thus the scenario that we'll describe below in detail.

For scenario 1 & 2, add -O verify-required to the ssh-keygen command to enforce PIN enforcement in key.

For scenarios 1, 2 & 3, do not add -O no-touch-required to the ssh-keygen command to enforce touch enforcement in key.

Linux

Create your key:

(do this on your laptop or desktop)

ssh-keygen -t ed25519-sk -O resident -O no-touch-required -O application=ssh:anunna -C "[Your comment to identify this key on the server]"

The options are:

• -t ed25519-sk : Type of key, this is the more secure option
• -O resident : Store the SSH key on your hardware key, makes it easier to use on another machine
• -O no-touch-required : No need to touch the hardware key every time
• -O application=ssh:anunna.wur.nl : identifier for the key on your hardware key
• -C "[Your comment to identify this key on the server]" : identifier for the key on the server

An example exchange looks like this:

user001@LAPTOP:~ % ssh-keygen -t ed25519-sk -O resident -O no-touch-required -O application=ssh:anunna -C "first.lastname@wur.nl"
Generating public/private ed25519-sk key pair.
You may need to touch your authenticator to authorize key generation.
Enter PIN for authenticator:
You may need to touch your authenticator again to authorize key generation.
Enter file in which to save the key (/Users/user001/.ssh/id_ed25519_sk):
Enter passphrase for "/Users/user001/.ssh/id_ed25519_sk" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/user001/.ssh/id_ed25519_sk
Your public key has been saved in /Users/user001/.ssh/id_ed25519_sk.pub

Copy your key:

To be able to log in, the server will have to have the public part of your key.

For that, copy the contents of your public key, in my case /Users/user001/.ssh/id_ed25519_sk.pub to $HOME/.ssh/authorized_keys

To allow touchless entry, we'll need to tell the SSH daemon to allow that:

# Copy over key
ssh login.anunna.wur.nl "umask 0077; mkdir -p ~/.ssh; echo 'no-touch-required $(cat ~/.ssh/id_ed25519_sk.pub)' >> ~/.ssh/authorized_keys"
# Check for key
ssh login.anunna.wur.nl 'tail -1 .ssh/authorized_keys'

Key use

On the machine that you created the key, there will be a stub file added to point ssh-agent to the hardware key, so that machine should work out of the box.

On other machines, you can load the private SSH key from the hardware key with

ssh-add -K 

After this all, you should be able to login without issue.

MacOS

For MacOS, we can mostly do the same as for Linux, except that we will have to install openssh, as the default SSH stack doesn't work with hardware keys.

So:

brew install openssh

Besides that, you will have to replace the MacOS ssh-agent with the one from openssh:

# Download the plist
curl --silent --output ~/Library/LaunchAgents/com.homebrew.ssh-agent.plist https://gist.githubusercontent.com/partikus/cd45013b1274af8ae63b17030d89176c/raw/d34dfae3872dec38137e8a51780fbcb95380034c/com.homebrew.ssh-agent.plist

# disable the default ssh-agent
launchctl disable gui/$UID/com.openssh.ssh-agent
launchctl stop gui/$UID/com.openssh.ssh-agent

# enable the homebrew ssh-agent 
launchctl bootstrap gui/$UID ~/Library/LaunchAgents/com.homebrew.ssh-agent.plist

# verify installation (you should see com.homebrew.ssh-agent)
launchctl list | grep ssh

If there are issues with the MacOS ssh-agent, try a reboot, do another verify, and only the homebrew one should be present.

After this, open a new terminal , and follow the Linux flow.

Windows

(needs to be filled by a Windows user)