Parlons SSH

‘une petite mise au point s’impose.

Alors loin de moi l’idée de faire un post « Best SSH practices in late 2023« , car je n’en ai absolument pas la prétention, mais j’aimerai simplement revenir sur plusieurs choses qui me hérissent les poils au quotidien ou bien que je trouve simplement utiles/sympathiques.

Oui, le RSA est dépassé

Alors oui et non. Mais en fait si.

Disons que oui, vous pouvez continuer à générer des clefs SSH en RSA 4096bits, aucun souci à ce niveau là. Mais bon, on est bientôt en 2024… quand vous voyez les autres algorithmes disponibles, pourquoi rester cantonné à RSA ? Mise à part pour des soucis de compatibilité :

1. RSA (Rivest–Shamir–Adleman) :
   • Type : Algorithme de clé asymétrique.
   • Principe : Basé sur la difficulté mathématique de factoriser de grands nombres premiers.
   • Avantages : Bien établi, largement pris en charge.
   • Inconvénients : Peut être plus gourmand en ressources que d’autres algorithmes plus récents.
     
2. DSA (Digital Signature Algorithm) :
   • Type : Algorithme de signature numérique.
   • Principe : Repose sur le problème du logarithme discret.
   • Avantages : Conçu spécifiquement pour la signature, était efficace pour cette tâche.
   • Inconvénients : OpenSSH itself le déconseille car peu sécurisé de nos jours.
     
3. ECDSA (Elliptic Curve Digital Signature Algorithm) :
   • Type : Algorithme de clé asymétrique basé sur les courbes elliptiques.
   • Principe : Utilise des propriétés mathématiques des courbes elliptiques.
   • Avantages : Plus efficace en termes de ressources que RSA, même niveau de sécurité avec des clés plus courtes.
   • Inconvénients : Moins répandu que RSA, mais gagne en popularité.
     
4. Ed25519 :
   • Type : Algorithme de clé asymétrique basé sur la courbe elliptique Curve25519.
   • Principe : Utilise des propriétés mathématiques spécifiques à la courbe Curve25519.
   • Avantages : Très efficace en termes de ressources, considéré comme sécurisé, gain de popularité.
   • Inconvénients : Moins largement pris en charge que RSA, mais de plus en plus adopté.

Comment ça j’ai demandé à ChatGPT de me les résumer pour pas gagner du temps… ? Mais enfin…

Ici le message à transmettre (mais qui n’engage que moi), c’est de passer enfin sur ECDSA.

A la limite je peux comprendre pour Ed25519, car c’est le plus récent des quatre, mais tout de même…

Tout aussi sécurisé et bien plus courtes 😐

Des commentaires

Alors si vous ne le saviez pas, mais j’en doute, on peut rajouter des commentaires dans ses clefs publiques. Par exemple :

ecdsa-sha2-nistp521 AAAAE2VjZHNhLXNoYTItbmlzdHA1MjEAAAAIbmlzdHA1MjEAAACFBABI2pzJN7KI2pk5Ol3hB2u6fvghu5vvqG0rJhkhsKtg6u2FBZzaTRHxD0Ykk+yHe+LeZiIZsJntMaNG8QFGiqUKeACYiE+UnCX2oKIo4TZMj77XKPIeizeNLmj7ax68XzlxuL9lkex0RXuSKJGTBPr0FTIkwVvoP5tQLGlkZE8ZWOTkYQ== XxD4rkGamerxX@PC-GAMING

Et oui, par défaut, quand on va ssh-keygen, SSH va rajouter notre nom d’utilisateur et notre nom d’hôte enfin de notre clef. Mais bon, dans le monde professionnel, ça peut le faire moyen… autant directement faire quelque chose de plus propre via l’argument -C :

ssh-keygen -t ed25519 -C "ansible_user - Prod02 - Paris"

Bon alors ici j’ai volontairement mis quelque chose à rallonge, mais sinon un simple « anthony@laptop22049 » suffit. On voit trop souvent des clefs avec des noms ésotériques, surtout à l’heure du Cloud…

Le randomart… on s’enfout ou bien ?

Alors là j’avoue que ça m’a toujours un peu questionné… si l’on se connecte à un serveur, et que la clef n’est pas la même qu’avant, on obtient un joli warning :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Que certains s’empressent de supprimer via un bon gros rm -r .ssh/known_hosts 🤪

Mais si je vous parle des Randomarts, ces images générées en même temps que votre paire de clefs, c’est car elles constituent une « sécurité supplémentaire » elles aussi, mais visuelle.

En effet, elles permettent de représenter visuellement la clef en question, alors certes ce n’est plus trop voir plus du tout utilisé aujourd’hui, mais si vous voulez vous amuser ou faire votre nerd, voilà comment rajouter la vérification lors de la connexion :

ssh anthony@206.149.54.22 -o VisualHostKey=yes

Il est aussi possible de garder l’option persistante en éditant son fichier SSH pour la rajouter :

VisualHostKey yes

L’accès root, c’est non

Pas la peine d’épiloguer sur ce point, mais on n’autorise pas l’accès SSH à root.

C’est tout, c’est comme ça 🤷‍♂️

Changer le port d’écoute…

Vaste débat attention. Y’a deux écoles bien distinctes :

• Oui, on change le port pour ralentir les éventuels attaquants ;
• Non, à part ralentir ça fait surtout chier les Sysadmins ;

Alors pour ma part, dans un contexte entreprise, je suis partisan de ne pas le changer, sauf « éventuellement » pour des assets Internet-Facing. Déjà que bien souvent la doc’ interne est foireuse, si en plus on s’amuse à changer des ports…

Mais dans un contexte privée, si vous hébergez un site web par exemple, là j’y serai favorable, simplement dans l’optique d’éviter d’avoir quantité folle de logs avec des randoms qui essaient « admin » ou encore « root » pour se connecter sur le port par défaut.

Protéger votre clef privée

Alors oui, ça peut être relou. Oui, dans certains contextes d’automatisation c’est la galère, mais par pitié, chiffrez votre clef privée !

En particulier sur vos serveurs, mais plus encore sur vos laptops.

Oui mais j’ai Bitlocker d’activé sur mon PC, même volé je risque rien.

Non Kévin, on chiffre tout de même sa clef.

Authentification par clefs publiques, voir activer la 2FA

Rien de spécial à dire ici, l’idéal quand c’est possible étant d’éviter l’utilisation de mots de passe.

Concernant la double authentification, je ferai sûrement un article à l’avenir, car j’avoue ne l’avoir encore jamais mis en place.. si certains ont des retours, je suis preneur !

RTFM

Pour finir, n’hésitez pas à lire la doc’ de chez FreeBSD concernant ce service, vous verrez qu’il existe une tonne d’options très utiles et que l’on active que très rarement… que ce soit le MaxAuthTries, le StrictModes, ClientAliveCountMax, et plus encore.

Clé ou clef ?

Ananas sur la pizza ou pas ?

En bref

Comme je l’avais dit en début de blog, j’ai décidé de ne pas me cantonner à de simples guides/astuces/tutoriels. Je me suis donc permis ce petit post pour parler de divers choses à propos de SSH en général, sous couvert de légèreté mais tout en essayant de promulguer quelques bons conseils.

Une fois n’est pas coutume, chaque choix est défendable et je ne prétends pas (encore ?) avoir un doctorat en cryptographie, cela ne reflète que mon opinion personnel ! 😉

Je n’ai pas non plus parlé des serveurs bastion, du port-knocking, ou encore de la limitation des cyphers côté serveur… sinon cet article n’en aurait jamais fini, mais j’en parlerai sûrement à un moment donné !

Sur ce, à la prochaine ! Ciao !