Générer des clés SSH qui tiennent la route - tutox.fr

[Ldfa]

Que tu sois Adminsys, dev ou geek tu as forcément été amené un jour à causer SSH avec tes machines. Je te passe les explications théoriques sur comment fonctionne le protocole ssh. Mais pour ceux qui se sentent légers sur le sujet, cet article est déjà un bon rappel.
Dans ce billet , nous allons surtout nous intéresser à la phase d’authentification. Tu sais, toujours cette histoire de clé privée et clé publique qui doivent permettre au client et au serveur de s’authentifier mutuellement et ainsi se faire confiance pour la suite des échanges. Cette étape est essentielle et c’est pourquoi nous allons voir comment faire pour générer des clés SSH modernes qui combinent performance et sécurité .

Générer sa paire de clés SSH… comme un noob

Pour créer sa paire de clés, en général on utilise l’utilitaire ssh-keygen. Et on va pas se mentir , nous sommes nombreux à l’utiliser avec des paramètres pompés à la va vite dans un tuto ou au mieux extraits de vagues souvenirs d’études antérieures.

Mais puisqu’on est entre nous, voici comment je m’y prenais en 2010 pour générer mes clés :

ssh-keygen -t rsa -b 1024

-t => on définit le type d’algo à utiliser
-b => on définit la taille de la clé (ici 1024 bits)

« Et de nos jours, seule la taille compte »

Ne rigolez pas je vois encore des sites où l’on peut retrouver cette commande au poil de paramètre près.Pourtant elle est totalement obsolète en matière de sécurité.

Depuis, vous allez voir je suis monté d’un cran niveau sécu, en multipliant la taille de la clé … par deux:

ssh-keygen -t rsa -b 2048

Mais est-ce vraiment ce qui se fait de mieux en terme de sécurité et de performance ?

« Remettre en question tes connaissances, tu sauras »

Un jour de crise existentielle, je me suis dis que ce serait pas mal d’améliorer un peu la sécu côté client ssh . C’est vrai quoi on parle toujours de durcissement de la conf ssh côté serveur (à juste raison) mais rarement côté client.

En fait, en crypto asymétrique le monde des algos se divise en 2 catégories:

• ceux qui factorisent des grands nombres premiers (RSA, DSA)
• ceux qui se basent sur des courbes elliptiques: les clés ECC avec ses algos ECDSA, Ed25519

Et ce sont bien ces derniers qui ont le vent en poupe.

En cherchant un peu sur le web , je me suis aperçu qu’ en 2020, ce n’est plus l’algo RSA qui est conseillé mais plutôt ECDSA.
Ce n’est pas moi qui le dit mais des gens très sérieux comme l’ANSSI. D’ailleurs voici un extrait de leur note de recommandations pour un usage sécurisé d’openSSH:

Lorsque les clients et les serveurs SSH supportent ECDSA, son usage doit être préféré à RSA.

Le hic c’est que la note date de 2015 et depuis ECDSA a pris du plomb dans l’aile notamment à cause :
–  d’une forte suspicion d’être backdooré par la NSA
-. une difficulté d’implémentation où il convient d’être très rigoureux, Sony en fait les frais avec le célèbre hack de 2010. Mais il faut bien avouer que ce n’était pas dû à une faiblesse de l’algo lui même.

C’est pourquoi on préférera conseiller l’utilisation de son petit frère: Ed25519 qui semble faire l’unanimité dans la communauté cybersécuritaire.

Au passage j’en profite pour demander si quelqu’un a un lien à recommander pour un guide de survie récent concernant openssh, qu’il n’hésite pas à le poster dans les commentaires.

Petit récap des recommandations :

Les recommandations concernant les algos de clés publiques à privilégier (ou pas):

• DSA -> à proscrire, ça n’est plus supporté depuis openssh v7
• RSA -> éprouvé et conseillé avec une taille de clé de 4096 bits. Compatible partout.
• ECDSA -> Conseillé par l’ANSSI mais a priori n’a pas la confiance de tout le monde
• ED25519 -> le dernier arrivé et le meilleur en termes de sécu et de performance.
  =>Clés plus petites, du coup plus rapides pour chiffrer/déchiffrer.
  Seul bémol , utilisable uniquement sur des distrib récentes (ex Debian 8 minimum). Donc oublier l’utilisation sur des routeurs ou switchs cisco qui implémentent de vieux algos; de toute façon oublier cisco tout court 🙂

Générer sa paire de clés à l’aide de l’algo Ed25519

Rien de bien sorcier pour une conf de base sur une distrib récente.

prérequis:
– posséder une version minimum d’openssh 6.5 (client et serveur)
ssh -V

Générer une paire de clés ed25519 de longueur fixe 256 bits:
ssh-keygen -t ed25519

Choisir une phrase de passe qui tienne la route.

Visualiser la clé publique et la clé privée :
ls -l ~/.ssh/

Copier sa clé publique sur un serveur:
ssh-copy-id -i .ssh/id_ed25519.pub nomduserveur

Côté serveur, bien vérifier dans /etc/ssh/sshd_config qu’il contient ses 3 lignes là :

HostKey /etc/ssh/ssh_host_ed25519_key
PasswordAuthentication no
PubkeyAuthentication yes

Liens pour aller plus loin:

http://www.informatix.fr/tutoriels/securite/ssh-les-principes-et-l-authentification-par-cryptographie-asymetrique-71
https://wiki.archlinux.org/index.php/SSH_keys#Choosing_the_authentication_key_type
https://blog.peterruppel.de/ed25519-for-ssh/
https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e8d60d3c54
https://sciencetonnante.wordpress.com/2010/12/03/protegez-vos-petits-secrets-grace-aux-nombres-premiers/

Afficher l’article complet