OpenSSH et FIDO/U2F  : exigez une clé de sécurité pour la connexion à vos serveurs

Mi-février, la version 8.2 d'OpenSSH voyait le jour et apportait une nouveauté importante : la possibilité de créer une paire de clés publique/privée nécessitant la présence d'une clé de sécurité pour qu'elle soit considérée comme valide, et permette la connexion à un serveur. Voici comment procéder.

Si la connexion sans mot de passe est une tendance « hype » dans les services en ligne, elle n'a rien de nouveau pour les administrateurs de serveurs. Mais plutôt que de reposer sur des solutions telles que des liens envoyés par email contenant un jeton temporaire ou des notifications sur smartphone, cela passe par une bonne vieille paire de clés publique/privée.

On peut ainsi accéder au terminal d'un serveur via OpenSSH sans avoir le moindre mot de passe à taper. Le serveur doit connaître la clé publique associée à une clé privée disponible sur la machine de l'utilisateur pour que cela fonctionne. Il reste tout de même possible d'ajouter une phrase de passe pour renforcer la sécurité, à la mode « ceinture bretelle »

Ainsi si le mot de passe est diffusé dans une fuite ou découvert, l'accès au serveur n'est pas compromis. Même chose si le fichier de la clé privée est récupéré par un acteur malveillant. Il faut disposer des deux pour assurer un accès. Avec la montée en puissance des clés de sécurité, leur intégration à OpenSSH et à ses mécaniques de connexion était attendue.

Pendant longtemps, il fallait bidouiller pour arriver à quelque chose d'à peu près exploitable. Fort heureusement, le travail sur des standards tels que FIDO a fini par payer : il est supporté dans la version 8.2 d'OpenSSH. Présente sur certaines distributions mettant rapidement leurs outils à jour, elle est désormais largement exploitable sous Linux.

Un point important, car pour profiter de cette nouveauté il faut que le client et le serveur soient à jour. Par contre, ne comptez pas en profiter sous Windows pour le moment, le portage n'a pas encore été effectué.

Créer une paire de clés, se connecter à un serveur

Tout d'abord, commençons par la base : comment se connecter à un serveur via OpenSSH ? Si vous savez déjà comment faire, passez à la suite. Sinon, voici quelques explications avec l'exemple le plus simple qui existe : celui d'un service de type Cloud. Pour nos tests du jour, nous nous reposerons sur l'offre de Scaleway dont l'interface est simple en la matière.

Commençons par créer une paire de clés publique/privée. Cela peut passer par l'outil intégré à votre système ou à d'autres comme PuttyGen sous Windows par exemple. Nous utilisons le classique ssh-keygen :

ssh-keygen -b 4096
ssh-keygen -t ecdsa -b 521
ssh-keygen -t ed25519

Ces trois commandes initient la création d'une paire de clés RSA (4096 bits), ECDSA (521 bits) ou ED25519. L'interface vous demandera alors de préciser un emplacement et un nom de fichier (scaleway dans notre exemple) et une phrase de passe à taper deux fois qui n'est pas obligatoire :

Generating public/private rsa key pair.
Enter file in which to save the key (/home/davlgd/.ssh/id_rsa): (/home/davlgd/.ssh/scaleway
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/davlgd/.ssh/scaleway.
Your public key has been saved in /home/davlgd/.ssh/scaleway.pub.

Comme le précise le texte ci-dessus, deux fichiers sont alors créés, par défaut dans le dossier caché .ssh de votre compte utilisateur. Sinon dans celui que vous avez indiqué. La pratique est la même, que ce soit sous Linux ou Windows. Vous pouvez dès le départ préciser l'emplacement final de vos clés de la sorte : 

ssh-keygen -b 4096 -f /home/davlgd/.ssh/scaleway

Le premier fichier (sans extension) contient la clé privée qui est une suite de caractères devant rester secrète. C'est pour cela qu'on l'accompagne en général d'une phrase de passe. L'autre ficher (avec une extension.pub) est la clé publique, qui n'a pas besoin d'être spécialement protégée. Au contraire, elle doit être transmise au serveur auquel on veut se connecter.

Pour cela, il faut tout d'abord en afficher le contenu : 

cat /home/davlgd/.ssh/scaleway.pub  // sous Linux
type /home/davlgd/.ssh/scaleway.pub // sous Windows

Dans le cas d'un service en ligne tel que Scaleway, il faut ensuite se rendre dans la section Credentials de l'interface utilisateur (qui est en anglais uniquement, malheureusement). Cliquez sur Add a news SSH Key, collez ensuite le contenu dans la partie principale. Indiquez un nom pour savoir à quelle machine elle correspond et validez le formulaire :

Chacune des clés est liée à votre compte. Elles permettent donc toutes de se connecter à l'ensemble de vos instances. Si vous ajoutez une clé, il faut que la liste soit mise à jour pour que les machines déjà en route puissent la prendre en compte. Cela intervient à deux moments : lorsque l'utilisateur tape la commande scw-fetch-ssh-keys --upgrade dans un terminal, ou lors d'un redémarrage si la machine est inaccessible via SSH.

Dans tous les cas, l'interface ne permet pas d'attribuer une clé à une instance en particulier. Il faut pour cela passer par des manipulations supplémentaires comme nous le verrons plus loin.

Une fois l'instance créée, vous pouvez vous y connecter depuis le poste client avec la commande suivante :

ssh -i emplacement_de_la_clé_privée root@ip_du_serveur

Si vous avez ajouté une phrase de passe à votre clé, elle vous sera demandée. Vous serez ensuite connecté avec le compte administrateur (root) de votre machine. Vous pouvez ainsi l'administrer, la mettre à jour, y installer des applications, créer d'autres comptes utilisateurs, lui attribuer des clés publiques permettant de se connecter, etc. 

Si jamais vous voulez utiliser OpenSSH pour vous connecter à un serveur local plutôt qu'une instance Cloud par exemple, vous pouvez éditer le fichier de configuration d'OpenSSH pour ajouter la possibilité de connexion via une paire de clés et indiquer celles devant être autorisées (mais cela pourra faire l'objet d'un prochain article plus détaillé) :

sudo nano /etc/ssh/ssh_config

N'hésitez pas à regarder du côté des recommandations de l'ANSSI concernant les procédures de sécurité à suivre.

Générer une paire de clés utilisant FIDO/U2F

Si vous voulez utiliser une clé de sécurité en complément de votre paire de clés publique/privée, il faudra bien entendu en avoir une sous la main. Pour le moment, cela concerne celles respectant la première version de FIDO et U2F (USB, Bluetooth ou NFC). Ce sont en général les plus accessibles, on en trouve dès 10 euros. 

Il faut également vérifier que vous disposez au moins de la version 8.2 d'OpenSSH sur votre machine locale et le serveur. Celle-ci est en général disponible avec les distributions en rolling release ou celles qui ont une politique de mise à jour rapide. C'est aussi le cas sur Fedora 32 et Ubuntu 20.04 selon nos constatations.

Pour le vérifier, tapez cette commande :

ssh -V

Pour notre test, nous avons utilisé une simple clé U2F de base. Une fois connectée à la machine, il suffit de demander la création d'une paire de clés en précisant un algorithme à utiliser. Deux possibilités sont offertes : ECDSA (Elliptic Curve Digital Signature Algorithm) et ED25519 (Edwards-curve Digital Signature Algorithm, SHA-2, Curve 25519).

L'une ou l'autre peut être utilisée, certaines clés de sécurité pourront ne fonctionner qu'avec l'une d'entre elles. Notez que l'utilisation de FIDO/U2F peut venir en complément d'une phrase de passe. Ainsi, pour se connecter un utilisateur devra disposer de la bonne clé privée, disposer d'une clé de sécurité connectée et connaître cette phrase.

ssh-keygen -t ecdsa-sk
ssh-keygen -t ed25519-sk

Attention tout de même : si vous perdez la clé de sécurité, que vous ne l'avez pas sous la main ou qu'elle est cassée, vous perdrez l'accès à votre serveur. Il est donc sage de garder une paire de clés classique pour une connexion de secours. Il est aussi possible d'exporter la clé privée de la clé de sécurité, tout est détaillé dans la documentation d'OpenSSH 8.2.

Vous avez aussi la possibilité de demander à ce qu'un appui de l'utilisateur ne soit pas nécessaire pour initier la connexion :

ssh-keygen -t ecdsa-sk -no-touch-required
ssh-keygen -t ed25519-sk -no-touch-required

Une fois la paire générée, il faut transmettre la clé publique au serveur. Problème : l'interface de Scaleway n'accepte pas ce nouveau format de clé publique pour le moment. Il faut donc procéder autrement.

Ajouter une clé publique FIDO/U2F à un serveur Scaleway

La procédure sera similaire chez d'autres fournisseurs de cloud ou avec un serveur maison, même s'il faudra en général l'adapter à la marge. L'objectif est d'ajouter la clé publique générée à la liste de celles acceptées.

Pour cela, il faut tout d'abord disposer d'une paire de clés classique pour se connecter au serveur. Par défaut, c'est le fichier authorized_keys du dossier .ssh qui contient la liste des clés publiques acceptées. Mais chez Scaleway, ce fichier est remis à zéro à chaque lancement de l'instance ou lorsque la commande scw-fetch-ssh-keys --upgrade est lancée.

Cela permet de s'assurer constamment que seules les clés validées pour le compte sont reconnues. Il existe néanmoins un moyen de contourner cela : en ajoutant les clés publiques de votre choix au fichier instance_keys. Ce dernier contient une liste de clés n'étant acceptées que sur une instance en particulier. Utilisez la commande suivante :

echo votre_clef_publique >> /root/.ssh/instance_keys
scw-fetch-ssh-keys --upgrade

Vous pouvez bien entendu adapter cette commande à d'autres utilisateurs. Seule contrainte en attendant que Scaleway gère ce type de clés directement depuis son interface en ligne : il faudra répéter cette procédure autant de fois que vous avez de serveurs où vous voulez que votre clé publique FIDO/U2F soit reconnue. N'hésitez donc pas à l'automatiser.