Générer des clés SSH qui tiennent la route

Dernière mise a jour 22 Juil 2020 a 08:51

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/

10 commentaires sur Générer des clés SSH qui tiennent la route

  1. Bonjour,

    en fait, concernant RSA, non seulement il est préférable d’utiliser à minimum une taille de 4096 bits, mais il est conseillé aussi d’utiliser la fonction de dérivation de clé PKBDF. Ce qui avec l’option ‘-o’ donne :

    ssh-keygen -t rsa -b 4096 -o -f ~/.ssh/id_rsa

    On peut même la durcir encore plus en lui spécifiant un nombre de « tours de moulinettes », grâce à l’option ‘-a’. Par défaut, cette valeur est de 16.
    Actuellement, il semble être considéré qu’une valeur de 64 est suffisante dans un contexte paranoïaque. Tel que :

    ssh-keygen -t rsa -b 4096 -o -f file_id_rsa

    Il est même possible de transformer une clé RSA précédemment créée, sans avoir spécifié la fonction de dérivation, tel que, par exemple :

    ssh-keygen -o -p -f file_id_rsa -a 64

    Concernant l’algorithme à courbe elliptique ed25519, en plus de ses avantages connus, il faut savoir que par défaut la génération de clé SSH avec, utilise aussi la fonction de dérivation de clé PKBDF, donc il n’y a pas besoin de spécifier l’option ‘-o’, mais on peut la durcir avec l’option ‘-a’ !

    Le détail concernant PKBDF est connu, mais peu d’articles de promotion de création de clé SSH, en parle.

    Pour finir, @antonof a raison de préciser la modification du fichier de config de SSH, en précisant les versions « sécurisées » pour :
    – les algorithmes de chiffrement : Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
    – les algorithmes d’échange de clés : KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
    – et, les « algorithmes » de code de messages d’authentification : MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com

    Malheureusement, pour certains serveurs SSH, tel que Dropbear (SSHv2 seulement) ou pour certains clients SSH, il est nécessaire de « baisser en qualité », autrement la connexion sera impossible.
    Là, encore soit le log d’authentification, soit le message d’erreur au moment de la connexion informe du problème en question, heureusement !

  2. @antanof et @PengouinPdt,
    Merci pour vos précisions très utiles! Je ne connaissais pas la fonction de dérivation PKBDF. J’avoue que voulais rester à un niveau technique « grand public ».
    Mais je vais quand même en toucher 2 mots ds l’article et renvoyer à vos commentaires car effectivement à travers mes recherches sur le net,je n’ai pas eu la chance de tomber sur des explications aussi claires que celles que vous avez pris le temps de fournir

Leave a Reply

Votre adresse de messagerie ne sera pas publiée.


*