Après Adieu GnuPG ! chiffrer des secrets sans GnuPG, suite de cette série de posts sur l'authentification forte : il s'agit maintenant de protéger mes clefs SSH pour m'authentifier et ce, avec des YubiKeys ne supportant pas GnuPG (tout jeton FIDO devrait convenir).

Depuis OpenSSH 8.2 (améliorations dans 8.3), les clefs SSH peuvent être protégées par FIDO U2F (et stockées sur le jeton). La spécification est dans le dépôt.

Avant de commencer, installer YubiKey manager pour changer le PIN de l'applet FIDO (différent de PIV, pas de PUK pour FIDO).

Générons une telle clef :

$ ssh-keygen -t ecdsa-sk -O resident -O verify-required -O application=ssh:perso
Generating public/private ecdsa-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/nomp/.ssh/id_ecdsa_sk):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/nomp/.ssh/id_ecdsa_sk
Your public key has been saved in /home/nomp/.ssh/id_ecdsa_sk.pub
The key fingerprint is:
SHA256:0uHAzPX9VEMlWe+fXVtwt/RCwGJTyO9+A2TcS43tO8g pc@plop
The key's randomart image is:
+-[ECDSA-SK 256]--+
|        .. +o o==|
|     + . .*....oo|
|      = ...=..+=+|
|       + .  =+=+*|
|      . S  + .o+=|
|       .    o ..O|
|           ....o+|
|            .Eoo |
|             . ..|
+----[SHA256]-----+

Pour les jetons FIDO (et pas FIDO2), seules les clefs P-256 sont possibles.

Ici, on stocke la clef SSH sur le jeton FIDO (-O resident) avec l'« application » ssh:perso (pour différencier les clefs si on doit en avoir plusieurs) ; par défaut, la chaîne ssh: est utilisée. Enfin, on impose la vérification du PIN de l'usager à chaque signature avec -O verify-required.

Déplaçons les fichiers /home/nomp/.ssh/id_ecdsa_sk et /home/nomp/.ssh/id_ecdsa_sk.pub. Avec :

$ ssh-keygen -K

on vérifie que la clef est extractible et donc correctement stockée sur le jeton (cette commande extrait la clef (privée) pour l'enregistrer sur le disque) ; évidemment, le PIN FIDO est demandé. On peut alors supprimer les fichiers /home/nomp/.ssh/id_ecdsa_sk*. On charge maintenant la clef avec la commande :

$ ssh-add -K

Le PIN FIDO est demandé. La commande :

$ ssh-add -L
sk-ecdsa-sha2-nistp256@openssh.com AAA...NoOg==

affiche la clef publique ; on note que son type est préfixé par sk- (pour security key).

NB : comme le jeton Yubico se bloque après trois tentatives erronées, un PIN de six caractères protège correctement la clef SSH.

Lors de chaque accès SSH, la YubiKey clignote et il faut appuyer sur le jeton pour que l'authentification se fasse si on n'a pas ajouté -O verify-required lors de l'étape de création. Sinon, le PIN est demandé.

Du point de vue de l'administrateur, il est possible d'appliquer des politiques d'authentification différentes selon qu'on s'authentifie avec une clef protégée par FIDO ou non. Le serveur peut requérir une preuve de présence (toucher la clef) lors de chaque authentification. Enfin, ces clefs peuvent être intégrées à une autorité de certification, comme les clefs SSH traditionnelles.

Imaginons deux groupes d'utilisateurs Unix. Un groupe, sksshusers dispose de clefs SSH protégées par FIDO, stockées dans des jetons comme les YubiKeys. Un autre groupe, ici sshusers, n'en dispose pas. Dans la configuration du daemon sshd(8) l'administrateur peut imposer des contraintes d'authentification différentes :

Match Group sksshusers,!sshusers Address *
    AuthenticationMethods publickey
    # generated by:
    # $ ssh -Q PubkeyAcceptedKeyTypes | grep sk- | tr '\n' ',' | sed -e 's/,$/\n/'
    PubkeyAcceptedKeyTypes sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com
    Match all

Match Group sshusers,!sshskusers Address *
    AuthenticationMethods publickey,password
    Match all

On peut ajouter une politique PubkeyAuthOptions, par exemple pour imposer la saisie du PIN (verify-required), que la clef ait été créée avec cette option ou pas.

Cette configuration offre une authentification renforcée : le groupe sshusers s'authentifie par clef SSH et mot de passe, le groupe sshusers s'authentifie par clef SSH et jeton FIDO. On peut ajouter une politique PubkeyAuthOptions, par exemple pour imposer la saisie du PIN (verify-required) du jeton FIDO, que la clef SSH ait été créée avec cette option ou pas.

NB : couplé à authpf(8) sous OpenBSD ou à un filtrage du propriétaire des sockets avec skuid dans nftables(8) sous Linux, on peut, sur une passerelle SSH, avoir des ACL par utilisateur… mais c'est une autre histoire.