Dans la base de code OpenSSH support expérimental de l'authentification à deux facteurs utilisant des dispositifs prenant en charge le protocole , développé par l'alliance . U2F permet de créer des jetons matériels peu coûteux pour confirmer la présence physique de l'utilisateur, dont l'interaction se fait via USB, Bluetooth ou NFC. De tels dispositifs sont promus comme moyen d'authentification à deux facteurs sur les sites, sont déjà pris en charge par les principaux navigateurs et sont fabriqués par divers producteurs, notamment Yubico, Feitian, Thetis et Kensington.
Pour interagir avec les dispositifs confirmant la présence de l'utilisateur, OpenSSH a ajouté un nouveau type de clé « sk-ecdsa-sha2-nistp256@openssh.com » (« ecdsa-sk »), qui utilise l'algorithme de signature numérique ECDSA (Elliptic Curve Digital Signature Algorithm) avec une courbe elliptique NIST P-256 et un hachage SHA-256. Les procédures d'interaction avec les jetons sont regroupées dans une bibliothèque intermédiaire qui est chargée de manière similaire à la bibliothèque pour le support de PKCS#11 et est un wrapper autour de la bibliothèque , fournissant des moyens de communication avec les jetons via USB (prenant en charge les protocoles FIDO U2F/CTAP 1 et FIDO 2.0/CTAP 2). La bibliothèque intermédiaire libsk-libfido2 préparée par les développeurs d'OpenSSH est intégrée à la composition principale de libfido2, tout comme pour OpenBSD.
Pour activer U2F, vous pouvez utiliser la dernière version de la base de code provenant du OpenSSH et la branche HEAD de la bibliothèque , qui inclut déjà la couche nécessaire pour OpenSSH.
Libfido2 fonctionne sous OpenBSD, Linux, macOS et Windows.
Pour l'authentification et la génération de clé, vous devez définir la variable d'environnement SSH_SK_PROVIDER, en spécifiant le chemin vers libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so), ou définir la bibliothèque via la configuration SecurityKeyProvider, puis exécuter « ssh-keygen -t ecdsa-sk » ou, si les clés sont déjà créées et configurées, se connecter au serveur avec « ssh ». Lors de l'exécution de ssh-keygen, la paire de clés créée sera enregistrée dans « ~/.ssh/id_ecdsa_sk » et pourra être utilisée de la même manière que d'autres clés.
La clé publique (id_ecdsa_sk.pub) doit être copiée sur le serveur dans le fichier authorized_keys. Du côté du serveur, seule la signature numérique est vérifiée, tandis que les interactions avec les jetons se font du côté client (il n'est pas nécessaire d'installer libsk-libfido2 sur le serveur, mais le serveur doit prendre en charge le type de clé « ecdsa-sk »). La clé privée générée (id_ecdsa_sk) est en réalité un descripteur de clé, formant la véritable clé uniquement en combinaison avec la séquence secrète stockée sur le jeton U2F.
Si la clé id_ecdsa_sk tombe entre les mains d'un attaquant, il aura également besoin d'accéder au jeton matériel pour passer l'authentification, sans lequel la clé privée sauvegardée dans le fichier id_ecdsa_sk est inutile. De plus, par défaut, lors de toute opération avec des clés (que ce soit lors de la génération ou de l'authentification), une confirmation locale de la présence physique de l'utilisateur est requise, par exemple, il est proposé de toucher le capteur sur le jeton, ce qui complique les attaques à distance sur les systèmes avec jeton connecté. Comme autre mesure de protection, lors du lancement de ssh-keygen, un mot de passe peut également être défini pour accéder au fichier contenant la clé.
La clé U2F peut être ajoutée à ssh-agent via « ssh-add ~/ .ssh / id_ecdsa_sk », mais ssh-agent doit être construit avec le support des clés « ecdsa-sk », une couche libsk-libfido2 doit être présente et l'agent doit s'exécuter sur le système auquel le jeton est connecté.
Un nouveau type de clé « ecdsa-sk » a été ajouté car le format des clés ecdsa d'OpenSSH diffère du format U2F pour les signatures numériques ECDSA en raison de champs supplémentaires.
Source : opennet.ru
