YubiKey/SSH
YubiKeys can be configured to authenticate SSH connections in multiple ways.
Many YubiKeys can be configured to provide FIDO/U2F authentication. OpenSSH 8.2p1+ supports ed25519-sk and ecdsa-sk algorithms.
Most YubiKeys can be configured to provide GPG authentication. In this mode of operation, the gpg-agent is used instead of the typical ssh-agent.
Introduction
YubiKeys provide several interfaces which can be used to authentication or encryption. Several of the authentication modules provided by YubiKeys can be used for SSH authentication. U2F is extremely secure, and can be set up in multiple ways without much configuration.
net-misc/openssh must be at least version 8.2p1 for FIDO/U2F functionality.
The YubiKey must have firmware 5.2.3+ to use ed25519 keys.
Additionally, SSH authentication is possible using the OpenPGP module on a YubiKey.
Installation
USE flags
USE flags for net-misc/openssh Port of OpenBSD's free SSH release
+pie
|
Build programs as Position Independent Executables (a security hardening technique) |
+ssl
|
Enable additional crypto algorithms via OpenSSL |
audit
|
Enable support for Linux audit subsystem using sys-process/audit |
debug
|
Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces |
kerberos
|
Add kerberos support |
ldns
|
Use LDNS for DNSSEC/SSHFP validation. |
legacy-ciphers
|
Enable support for deprecated, soon-to-be-dropped DSA keys. See https://marc.info/?l=openssh-unix-dev>m=170494903207436>w=2. |
libedit
|
Use the libedit library (replacement for readline) |
livecd
|
Enable root password logins for live-cd environment. |
pam
|
Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip |
security-key
|
Include builtin U2F/FIDO support |
selinux
|
!!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur |
static
|
!!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically |
test
|
Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) |
verify-sig
|
Verify upstream signatures on distfiles |
xmss
|
Enable XMSS post-quantum authentication algorithm |
The security-key
USE flag is not enabled by default and must be enabled for U2F/FIDO support.
Emerge
root #
USE=security-key emerge --ask net-misc/openssh
The
security-key
USE flag must be set for U2F functionality.If using gpg-agent:
root #
emerge --ask app-crypt/gnupg
The smartcard use flag must be set to use gpg with YubiKeys.
Configuration
GPG
To configure GPG keys, the following article can be followed: Configuring GPG keys on a YubiKey
The general process is to generate the keys, then load them onto the YubiKey.
U2F
There are two main ways U2F can be used on a YubiKey.
The first method, Non-Discoverable credential mode, requires the generation of -sk variant keys outside of the YubiKey. These keys must be securely stored, but are used in conjunction with the YubiKey for authentication. This method ensures more separation of factors, but is not suitable for environments where the private key cannot be safely stored.
The second method, Discoverable (resident) mode stores the -sk variant key on the YubiKey's storage, and enables the usage of the key in more hostile environments, but also means a attacker could potentially authenticate using the YubiKey given the private key, and U2F key are both in one place.
The U2F master key is not accessible, and is only used internally. It is regenerated every time the module is reset and essentially used as a seed for U2F keys.
Non-Discoverable
With the YubiKey inserted, execute:
user $
ssh-keygen -t ed25519-sk
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 (/home/larry/.ssh/id_ed25519_sk): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/larry/.ssh/id_ed25519_sk Your public key has been saved in /home/larry/.ssh/id_ed25519_sk.pub The key fingerprint is: SHA256:HjLrXXHoW/xllAnBFRw7QecrY97V+ezZTQE69wBrjOcv larry@gentoo The key's randomart image is: +[ED25519-SK 256]-+ | | | o | | . . o + | | . + .o* | | .o + SoBo | | +. .oXoE | |..o. +O =.. | |. o+ .o.=oo | | .**=***. | +----[SHA256]-----+
Optionally, an ecdsa-sk key can be used.
First, ssh-keygen will prompt for the YubiKey's FIDO PIN (Enter PIN for authenticator:
)
Then, it will prompt for a password to protect the private key with Enter passphrase (empty for no passphrase):
.
Finally, it will prompt for a private key passphrase confirmation with Enter same passphrase again:
.
The file permissions of the private key must be 0600.
Destination configuration
To export public keys associated with keys in the current ssh agent, ssh-add -L can be used:
user $
ssh-add -Lsk-ssh-ed25519@openssh.com AAAAW2XXFA0S2f2tHUFyEb6ktQmtjcpfO2McZKg2r/tfnqeSjMSHDNfdJ32OI0qF5M9NsVmeYcNZwldwZvh35Pbq+kaaAgVoEcB= larry@gentoo
The public key must be added to ~/.ssh/authorized_keys on the destination server, in the format:
# {key type} {pubkey} {name} {options}
sk-ssh-ed25519@openssh.com AAAAW2XXFA0S2f2tHUFyEb6ktQmtjcpfO2McZKg2r/tfnqeSjMSHDNfdJ32OI0qF5M9NsVmeYcNZwldwZvh35Pbq+kaaAgVoEcB= larry@gentoo verify-required
verify-required is not required but is recommended, this prompts for presence detection when logging in.
Usage
Once the keys are created and deployed on the destination, they are ready to be used.
ssh-agent U2F configuration
The ssh-agent is not required, but is helpful as it can store keys. It can be started with:
user $
eval "$(ssh-agent -s)"
Successful execution should return the PID for the created agent.
ssh-agent instances created this way only apply to the current shell session.
With an active ssh-agent keys can be added using ssh-add {keyfile}:
user $
ssh-add example_key_file_ed25519_sk
Identity added: example_key_file_ed25519_sk (larry@gentoo)
The loaded keys can be viewed with:
user $
ssh-add -Lsk-ssh-ed25519@openssh.com AAAAW2XXFA0S2f2tHUFyEb6ktQmtjcpfO2McZKg2r/tfnqeSjMSHDNfdJ32OI0qF5M9NsVmeYcNZwldwZvh35Pbq+kaaAgVoEcB= larry@gentoo
Once the keys are installed, ssh can be used without entering a password if the private key is already loaded into the ssh-agent.
user $
ssh remoteserver
Confirm user presence for key ED25519-SK SHA256:pdjHnsEQIzUfAyofW/Ff9KMVrqEahJPxrumDHzSr4vuN8h user@remoteserver ~ $
U2F Agentless
If an agent is not being used, the key can be manually specified, requiring the key password on every usage:
user $
ssh -i .ssh/id_ed25519_sh remoteserver
Enter passphrase for key '.ssh/id_ed25519_sk': Confirm user presence for key ED25519-SK SHA256:pdjHnsEQIzUfAyofW/Ff9KMVrqEahJPxrumDHzSr4vuN8h user@remoteserver ~ $
GPG
If the OpenGPG Authentication key is being used, the GPG agent can be activated with:
user $
export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
Once activated, the gpg-agent can be used like a typical ssh-agent
See also
- SSH — the ubiquitous tool for logging into and working on remote machines securely.