Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

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

Une procédure à répandre !
Internet 8 min
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 commandent 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 :

Scaleway Add SSH Key

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 ED2259 (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.

35 commentaires
Avatar de oursgris Abonné
Avatar de oursgrisoursgris- 05/05/20 à 13:40:50

ca va mettre du temps pour arriver sur debian stable.
est ce que qu'il y a des choses à savoir sur les clefs FIDO  ?

Avatar de psn00ps Abonné
Avatar de psn00pspsn00ps- 05/05/20 à 13:51:30

ne pas oublier de sécuriser le compte qui contient les clés avec password/123456 - sans oublier le post it - :fumer:

Avatar de David_L Équipe
Avatar de David_LDavid_L- 05/05/20 à 13:53:47

Debian Stable est encore en version 7.9 pour le moment, mais la 8.2 est dans Testing.

psn00ps a écrit :

ne pas oublier de sécuriser le compte qui contient les clés avec password/123456 - sans oublier le post it - :fumer:

La sécurité est un ensemble ;) (Mais Scaleway gère la 2FA, pas encore via WebAuthn par contre)

Édité par David_L le 05/05/2020 à 13:55
Avatar de white_tentacle Abonné
Avatar de white_tentaclewhite_tentacle- 05/05/20 à 14:13:48

Il m’a fallu du temps pour comprendre pourquoi ça fonctionne. ecdsa-sk -> le sk est pour « secure-key ». J’imagine que si deux clés de sécurité sont branchées sur la machine, ça va probablement faire de la merde…

Conceptuellement, avoir mis la destination dans laquelle stocker la clé au niveau du type de clé est un choix étonnant.

Avatar de bilbonsacquet Abonné
Avatar de bilbonsacquetbilbonsacquet- 05/05/20 à 14:22:36

Bon tuto, par contre utiliser le connexion root et en plus en SSH, c'est pas le plus conseillé ;)

Il faut bien configurer la propriété PermitRootLogin pour uniquement autoriser les connexions via la clef (PermitRootLogin without-password).

Édité par bilbonsacquet le 05/05/2020 à 14:24
Avatar de David_L Équipe
Avatar de David_LDavid_L- 05/05/20 à 14:25:20

C'est la procédure de base pour la première connexion à un serveur chez Scaleway (entre autres). Comme dit, rien n'empêche ensuite de configurer aux petits oignons (ou d'aller coller un cloud init spécifique, mais ce n'était pas trop le sujet ici :D)

Édité par David_L le 05/05/2020 à 14:25
Avatar de KP2 Abonné
Avatar de KP2KP2- 05/05/20 à 15:07:01

Super !
Je commençais à m’intéresser au sujet, voilà un tuto qui tombe à pic.

:inpactitude:

Avatar de Kazer2.0 Abonné
Avatar de Kazer2.0Kazer2.0- 05/05/20 à 15:07:35

Me semble que Debian désactive le root login par défaut maintenant.

J'ai pas encore mis en place car c'était le bordel, mais je vais me garder ce tuto sous le coude pour mes serveurs maison vu que ça a l'air plus simple à mettre en place.

Je me demande si on peut faire de la double-clef d'ailleurs, genre PermitRootLogin à false, tu te log avec une clef à ton user et tu as besoin d'une deuxième clef pour faire un su (ça fait bourrin mais c'est juste par curiosité. De toute façon il y a toujours moyen de faire plus bourrin, en rajoutant du port knocking encore par dessus :transpi: )

Avatar de eglyn Abonné
Avatar de eglyneglyn- 05/05/20 à 16:30:13

Je n'ai jamais testé Scaleway, mais le port SSH est forcément accessible de l'extérieur ?

Je veux dire, on ne peut pas changer le port SSH et configurer firewalld pour n'autoriser qu'une IP à s'y connecter ?

Avatar de David_L Équipe
Avatar de David_LDavid_L- 05/05/20 à 16:38:53

Tu peux modifier les paramètres des ports dans l’interface de gestion en plus de ce que le système permet. Par contre faut penser à gérer les accès avant de tout fermer sinon l’instance partira à la poubelle 😀

Il n'est plus possible de commenter cette actualité.
Page 1 / 4