Ma configuration SSH · Accueil
↓<br>Aller au contenu
Accueil
Accueil
Sommaire
Sommaire
Dès lors qu’on administre des serveurs à distance, SSH devient la norme. Le<br>problème c’est que bien souvent la configuration par défaut n’est pas<br>suffisamment sécurisée. Voyons donc comment configurer OpenSSH de manière à<br>avoir quelque chose de vraiment solide côté serveur.
Les clés serveur et client
Le protocole SSH permet trois méthode d’authentification : par mot de passe,<br>clé ou certificat. Nous verrons plus loin pour désactiver l’authentification<br>par mot de passe, ce qui nous laisse avec les clés et les certificats. Les<br>certificats nécessitant de déployer une autorité de certification, c’est une<br>solution principalement utilisée en entreprise.
Le client et le serveur ont chacun une clé ou certificat. Actuellement, trois<br>principaux algorithmes sont supportés : RSA, ECDSA et Ed25519. D’une manière<br>général, il est préférable de bannir RSA qui est un véritable champ de mines.<br>Il nous reste donc deux algorithmes basés sur les courbes elliptiques. ECDSA<br>est standardisé par le NIST mais critiqué pour sa difficulté d’implémentation<br>ainsi que pour sa conception sous-optimale. Nous préférerons donc utiliser<br>exclusivement Ed25519.
La liste des algorithmes supportés par la commande ssh -Q HostKeyAlgorithms.<br>Notez que les variantes sk concernent les clés de sécurité (SK pour Security<br>Key). Suivant votre situation, vous pouvez ou non les utiliser.
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com<br># HostKeyAlgorithms sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com<br>PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com<br># PubkeyAcceptedAlgorithms sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com
L’échange de clés
Afin de pouvoir échanger de manière chiffrée, le serveur et le client doivent<br>se mettre d’accord sur une clé. Ceci est donc logiquement réalisé à l’aide d’un<br>protocole d’échange de clé basé sur la cryptographie asymétrique.
Si vous avez suivi l’actualité de ces dernières années, vous savez qu’une des<br>craintes actuelles est l’apparition d’un ordinateur quantique suffisamment<br>puissant pour casser les protocoles classiques de cryptographie asymétrique.<br>Une technique fréquente des services de renseignement est celle du « stockons<br>aujourd’hui, déchiffrons demain » qui consiste à enregistrer dès à présent tout<br>ce qui peut s’avérer utile dans l’espoir de pouvoir un jour obtenir le<br>technologie nécessaire pour le déchiffrer. Cette technique nous impose<br>d’utiliser dès à présent des algorithmes post-quantiques afin de ne pas se<br>retrouver en mauvaise posture le moment venu.
Le RSSI et la cryptographe
Le RSSI, ayant procrastiné
Tout l’été,
Se trouva fort dépourvu
Quand l’ordinateur quantique fut venu :
Pas un seul petit morceau
De RSA ou de courbe elliptique.
Il alla crier famine
Chez la cryptographe sa voisine,
La priant de lui prêter
Quel qu’algorithme pour subsister
Jusqu’à la prochaine version.
« Je vous paierai, lui dit-il,
Avant l’Oût, foi d’administratif,
Intérêt et principal. »
La cryptographe n’est pas prêteuse :
C’est là son moindre défaut.
Que faisiez-vous à la période de transition ?
Dit-elle à cette emprunteur.
– Nuit et jour à tout venant
J’assistais à des réunions, ne vous déplaise.
– Vous assistiez à des réunions ? J’en suis fort aise.
Eh bien ! notifiez votre violation de donnés maintenant.
La commande pour connaître les algorithmes d’échange de clés supportés par<br>OpenSSH est ssh -Q kex.
Notons qu’à cause du manque de recul sur ces algorithmes post-quantiques, la<br>démarche la plus sécuritaire à prendre est d’utiliser un algorithme hybride qui<br>utilise donc à la fois un algorithme classique et un algorithme post-quantique.<br>Plusieurs mode d’hybridations sont possibles, mais cela dépasse grandement le<br>sujet de cet article.
Une première expérimentation d’algorithme post-quantique hybride basée sur NTRU<br>(Streamlined NTRU Prime en vrai, d’où l’abréviation sntrup mais ne chipotons<br>pas) et X25519 est arrivée dans OpenSSH en 2019 grace à la version 8.0. Cette<br>expérimentation a dû être corrigée d’une manière non-rétro-compatible en 2021<br>(OpenSSH v8.5). En 2022, cette nouvelle version a été introduite dans la liste<br>des algorithmes supportés par défaut (OpenSSH v8.9) puis a été propulsée en<br>tête de cette liste (OpenSSH v9.0) afin d’être utilisée par défaut.
Les expert·e·s en cryptographie ne sont pas impressionné·e·s par NTRU. (source)
En 2024, OpenSSH 9.9 introduit un nouvel algorithme post-quantique hybride basé<br>cette fois sur ML-KEM (la standardisation par le NIST de Kyber) et X25519. En<br>2025, avec OpenSSH 10.0 ce nouvel algorithme est désormais utilisé par défaut à<br>la place du précédent.
En conséquent, si l’on...