Dès lors qu’on administre des serveurs à distance, SSH devient la norme. Le problème c’est que bien souvent la configuration par défaut n’est pas suffisamment sécurisée. Voyons donc comment configurer OpenSSH de manière à 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, clé ou certificat. Nous verrons plus loin pour désactiver l’authentification par mot de passe, ce qui nous laisse avec les clés et les certificats. Les certificats nécessitant de déployer une autorité de certification, c’est une solution principalement utilisée en entreprise.
Le client et le serveur ont chacun une clé ou certificat. Actuellement, trois principaux algorithmes sont supportés : RSA, ECDSA et Ed25519. D’une manière général, il est préférable de bannir RSA qui est un véritable champ de mines. Il nous reste donc deux algorithmes basés sur les courbes elliptiques. ECDSA est standardisé par le NIST mais critiqué pour sa difficulté d’implémentation ainsi que pour sa conception sous-optimale. Nous préférerons donc utiliser exclusivement Ed25519.
La liste des algorithmes supportés par la commande ssh -Q HostKeyAlgorithms.
Notez que les variantes sk concernent les clés de sécurité (SK pour Security
Key). Suivant votre situation, vous pouvez ou non les utiliser.
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
# HostKeyAlgorithms sk-ssh-ed25519@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
# 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 se mettre d’accord sur une clé. Ceci est donc logiquement réalisé à l’aide d’un 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 craintes actuelles est l’apparition d’un ordinateur quantique suffisamment puissant pour casser les protocoles classiques de cryptographie asymétrique. Une technique fréquente des services de renseignement est celle du « stockons aujourd’hui, déchiffrons demain » qui consiste à enregistrer dès à présent tout ce qui peut s’avérer utile dans l’espoir de pouvoir un jour obtenir le technologie nécessaire pour le déchiffrer. Cette technique nous impose d’utiliser dès à présent des algorithmes post-quantiques afin de ne pas se 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
OpenSSH est ssh -Q kex.
Notons qu’à cause du manque de recul sur ces algorithmes post-quantiques, la démarche la plus sécuritaire à prendre est d’utiliser un algorithme hybride qui utilise donc à la fois un algorithme classique et un algorithme post-quantique. Plusieurs mode d’hybridations sont possibles, mais cela dépasse grandement le sujet de cet article.
Une première expérimentation d’algorithme post-quantique hybride basée sur NTRU
(Streamlined NTRU Prime en vrai, d’où l’abréviation sntrup mais ne chipotons
pas) et X25519 est arrivée dans OpenSSH en 2019 grace à la version 8.0. Cette
expérimentation a dû être corrigée d’une manière non-rétro-compatible en 2021
(OpenSSH v8.5). En 2022, cette nouvelle version a été introduite dans la liste
des algorithmes supportés par défaut (OpenSSH v8.9) puis a été propulsée en
tête de cette liste (OpenSSH v9.0) afin d’être utilisée par défaut.
En 2024, OpenSSH 9.9 introduit un nouvel algorithme post-quantique hybride basé cette fois sur ML-KEM et X25519, qui est la standardisation par le NIST de Kyber. En 2025, avec OpenSSH 10.0 ce nouvel algorithme est désormais utilisé par défaut à la place du précédent.
En conséquent, si l’on n’utilisez que des versions récentes d’OpenSSH, il est
préférable de n’autoriser que l’algorithme mlkem768x25519-sha256. Si vous
avez des versions un peu moins à jour (Debian bookworm sans les backports,
Ubuntu 22.04 LTS, 24.04 LTS et 24.10), il est possible d’ajouter
sntrup761x25519-sha512 et sntrup761x25519-sha512@openssh.com. Les versions
plus anciennes (Debian bullseye) ne supportant pas ces algorithmes
post-quantiques devraient être bannies.
KexAlgorithms mlkem768x25519-sha256
# Retro-compatibility only:
# KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com
Le chiffrement #
Une fois l’échange de clés effectué, les communications sont chiffrées à l’aide
d’un algorithme de chiffrement symétrique. La liste des algorithmes supportés
est disponible avec la commande ssh -Q cipher.
De nos jours, ce qui se fait de mieux ce sont des algorithmes de chiffrement authentifié avec données associées (AEAD). Il nous faut donc ne garder que ces modes là, ce qui restreint grandement la liste des possibles.
Si les algorithmes AEAD incluent de base un code d’authentification (MAC)
permettant de vérifier son intégrité, ce n’était pas le cas des algorithmes
plus anciens. Il est donc possible de définir les algorithmes utilisés pour
calculer le MAC des messages. Je ne sais pas si c’est très utile dans le cas
présent dans la mesure où nous n’avons autorisé que des algorithmes AEAD, mais
par précaution restreignons les MAC possibles aux seuls algorithmes reconnus
comme fiable. La liste est disponible avec la commande ssh -Q mac. Notons
qu’ici les algorithmes ne disposant pas de la mention etm
(encrypt-then-mac) fonctionnent en mode mac-then-encrypt et sont donc à
bannir.
Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
L’authentification #
Si vous pensiez que pour désactiver l’authentification par mot de passe il
suffisait de passer PasswordAuthentication à no, j’ai une mauvaise pour
vous. En effet, beaucoup de configurations par défaut activent, à raison,
UsePAM. Or, l’authentification interactive de PAM permet également de
s’authentifier avec un mot de passe. Bref, il nous faut également désactiver
KbdInteractiveAuthentication. Et tant que nous y sommes, désactivons
également les mots de passe vides, juste au cas où.
Afin d’éviter certains abus d’authentification, réduisons le nombre de tentative par connexion ainsi que le temps que chaque connexion peut rester sans s’authentifier.
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
MaxAuthTries 2
LoginGraceTime 30
Divers #
Maintenant, assurons nous de quelques paramètres qui améliorent un peu la sécurité.
PrintLastLogpermet, à la connexion, d’afficher la dernière fois où l’on s’est connecté ;StrictModespermet de s’assurer que les fichiers des utilisateurs ne sont pas librement accessibles ;PermitUserEnvironmentdéfinit s’il est possible où non de définir des variables d’environnement dans la configuration, ce que l’on évitera de faire ;AllowTcpForwardingpermet d’autoriser ou non les redirections TCP, ce que l’on évitera ;GatewayPortspermet de spécifier si les machines distantes sont autorisées à se connecter à des ports redirigés pour le client ;X11Forwardingpermet d’autoriser ou non les redirections du protocole graphique X11, ce que l’on évitera.
PrintLastLog yes
StrictModes yes
PermitUserEnvironment no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
Audit #
Afin de vous assurer de la bonne configuration d’un serveur SSH, il est possible d’utiliser l’outil ssh-audit. Cet outil est vraiment bien fait, mon seul reproche si j’ose dire c’est qu’il n’est sans doute pas assez paranoïaque à mon goût.
$ ssh-audit "example.org"
Et bien entendu, si vous avez besoin de diagnostiquer un problème de connexion
ou bien juste vérifier ce que fait votre client, vous pouvez toujours lancer
ssh en mode verbose. Plus vous ajoutez de v plus le log sera complet. Notez
que chaque ligne commence par une indication du niveau de log l’ayant
déclenchée (debug1, debug2, debug3).
$ ssh -v "example.org"
$ ssh -vv "example.org"
$ ssh -vvv "example.org"
Fichiers finaux #
J’ai choisi de diviser ma configuration en plusieurs fichiers. À cette fin, il
faut commencer par s’assurer que le fichier /etc/ssh/sshd_config contienne la
ligne permettant d’inclure les autres fichiers de configuration :
Include /etc/ssh/sshd_config.d/*.conf
J’ai donc d’abord créé un fichier de durcissement générique qui contient tout
ce qui est commun à l’ensemble de mes machines. C’est le fichier
/etc/ssh/sshd_config.d/10-hardened.conf.
#
# Hardened OpenSSH configuration
#
# Host and client keys
HostKeyAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
PubkeyAcceptedAlgorithms ssh-ed25519,ssh-ed25519-cert-v01@openssh.com
# Key exchange and encryption
KexAlgorithms mlkem768x25519-sha256
Ciphers chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com
# Authentication
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
MaxAuthTries 2
LoginGraceTime 30
# Misc
PrintLastLog yes
StrictModes yes
PermitUserEnvironment no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
Ensuite, vient un fichier spécifique pour chaque machine qui permet de limiter
les utilisateurs autorisés. C’est le fichier
/etc/ssh/sshd_config.d/20-users.conf.
# PermitRootLogin prohibit-password
PermitRootLogin no
AllowUsers derpina toto
Alternatives à OpenSSH #
OpenSSH n’est pas la seule implémentation du protocole SSH : deux alternatives bien connues sont Dropbear et wolfSSH. Le problème de ces alternatives est qu’elles sont plutôt destinées aux systèmes embarqués et ne sont donc pas configurables comme peut l’être OpenSSH. À la place il faut de les compiler avec les options que l’on souhaite. Les paquets pré-compilés que vous pouvez trouver dans certaines distributions ne sont donc pas forcément adaptés et peuvent inclure des paramètres dangereux que vous ne pourrez pas toujours désactiver.