OpenSSH 10.4 est là : ce que la nouvelle version change pour vos serveurs

OpenSSH 10.4 est sorti le 6 juillet 2026. Cette version corrige huit failles de sécurité touchant sftp, scp et sshd, introduit trois changements potentiellement incompatibles avec vos configurations existantes, et pose une première pierre vers les signatures post-quantiques dans le protocole SSH. Rien de spectaculaire en apparence, mais assez de détails techniques pour mériter un vrai passage en revue avant de lancer la mise à jour sur votre parc.

On fait le tri entre ce qui est urgent, ce qui peut casser votre production si vous ne vérifiez rien avant de déployer, et ce qui reste encore expérimental.

OpenSSH, le composant qu'on ne remarque que quand il casse

Petit rappel pour ceux qui découvrent le sujet : OpenSSH est l'implémentation open source du protocole SSH utilisée par la quasi-totalité des serveurs Linux et BSD, une bonne partie du parc macOS, et une large majorité des équipements réseau pour l'administration à distance. C'est aussi le socle des transferts de fichiers (sftp, scp) et de nombreux outils qui s'appuient dessus en coulisse : Git over SSH, rsync, Ansible, et une bonne partie de votre CI/CD dès qu'elle se connecte à des serveurs distants. Un composant tellement central qu'une mise à jour mal préparée peut vous couper l'accès à toute votre infrastructure.

Trois changements à vérifier avant de déployer

Le changelog officiel liste trois changements classés « potentiellement incompatibles ». Ce sont ceux qui méritent votre attention en priorité, avant même de regarder les correctifs de sécurité.

• La sortie de « sshd -G » change de casse. Le mode de dump de configuration écrit désormais les directives en casse mixte (par exemple PubkeyAuthentication) au lieu du tout-minuscule utilisé jusqu'ici. Si vous avez des scripts qui parsent cette sortie de façon sensible à la casse, pour de l'audit de configuration ou de la documentation automatique, ils vont se retrouver silencieusement cassés après la mise à jour.
• Le sandbox seccomp devient fatal en cas d'échec. Sur Linux, si sshd n'arrive pas à activer le sandbox SECCOMP ou NO_NEW_PRIVS, il refuse désormais de démarrer, alors qu'il se contentait auparavant de logger l'erreur et de continuer. C'est le bon réflexe de sécurité (fail closed plutôt que fail open), mais il peut surprendre sur des noyaux anciens ou des conteneurs qui ne supportent pas ces fonctionnalités. Le projet recommande de désactiver le sandbox à la compilation sur ces systèmes plutôt que de compter sur la tolérance de sshd.
• Le protocole de transport devient plus strict pendant une réexchange de clés post-authentification. ssh et sshd déconnectent désormais un pair qui envoie des messages hors réexchange de clés à ce moment précis, conformément à la section 7.1 de la RFC 4253. Jusqu'ici, un pair malveillant pouvait continuer à envoyer ce type de messages sans être inquiété, ce qui les faisait s'accumuler en mémoire jusqu'à saturation. Signalé par Marko Jevtic.

Les failles de sécurité corrigées

Le gros du changelog est sécurité. Huit correctifs sont listés, avec des profils de risque très différents selon votre configuration :

• sftp, téléchargement en ligne de commande. Avec une commande du type sftp host:/path ., un serveur malveillant pouvait forcer le téléchargement d'un fichier vers un emplacement inattendu. Faille identifiée par le Swival Security Scanner.
• scp, copie entre deux serveurs distants. Un serveur malveillant pouvait écrire des fichiers dans le répertoire parent du dossier cible lors d'une copie remote-to-remote. Même origine : Swival Security Scanner.
• internal-sftp, troncature silencieuse de ligne de commande. Sur l'implémentation interne du serveur SFTP (non activée par défaut), les lignes de commande étaient tronquées après le neuvième argument : une option de sécurité placée en dixième position ou plus était silencieusement ignorée. Signalé par Steve Caffrey.
• Déni de service pré-authentification via GSSAPI. Quand GSSAPIAuthentication est activé (désactivé par défaut), un déni de service était possible avant authentification, sans être bloqué par MaxAuthTries. Signalé par Manfred Kaiser du milCERT autrichien.
• Délai minimum d'authentification pas toujours appliqué. Plusieurs cas où ce délai de protection n'était pas correctement appliqué ont été corrigés. Signalé par l'équipe vulnérabilités d'Orange Cyberdefense.
• Usage après libération mémoire côté client ssh. Si le serveur change sa clé d'hôte pendant une réexchange de clés, le client pouvait déclencher un use-after-free. Signalé par Zhenpeng Lin.
• DisableForwarding n'écrasait pas PermitTunnel. Configurer DisableForwarding=yes ne désactivait pas PermitTunnel=yes comme documenté (PermitTunnel reste désactivé par défaut). Signalé indépendamment par Huzaifa Sidhpurwala (Red Hat) et Marko Jevtic.
• Note de documentation sur GSSAPIStrictAcceptorCheck. Cette option n'est pas efficace lorsque le serveur est joint à un Active Directory Windows. Signalé par Yarin Aharoni de Safebreach.

Concrètement, si vous n'utilisez ni GSSAPI ni internal-sftp, une bonne partie de cette liste ne vous concerne pas directement. Mais les correctifs sftp et scp touchent des usages par défaut, et les bugfixes additionnels (lectures hors limites dans sftp, validations de configuration renforcées) justifient à eux seuls la mise à jour.

Les nouveautés : post-quantique et un moteur de motifs plus robuste

• Signature post-quantique composite, expérimentale. OpenSSH 10.4 ajoute un support expérimental pour un schéma combinant ML-DSA-44 et Ed25519, tel que défini dans le brouillon draft-miller-sshm-mldsa44-ed25519-composite-sigs. Non activé par défaut : il faut l'ajouter explicitement à HostKeyAlgorithms ou PubkeyAcceptedAlgorithms, et générer une clé avec ssh-keygen -t mldsa44-ed25519.
• Nouveau moteur de correspondance de motifs. Le comparateur de wildcards, utilisé notamment dans les directives Match et AllowUsers, est réécrit avec une implémentation basée sur un automate à états finis non déterministe (NFA). L'ancienne implémentation pouvait avoir un comportement exponentiel sur certains motifs limites, ce risque disparaît.

Comment mettre à jour sans mauvaise surprise

Avant de déployer sur votre parc, quelques vérifications simples évitent le mauvais réveil. Connaître votre version actuelle :

ssh -V

Puis la mise à jour selon votre distribution (gestionnaire de paquets, ou compilation depuis les sources avec les checksums publiés dans le changelog officiel). Avant de redémarrer le service, validez toujours la configuration :

sshd -t

Si vous avez des scripts qui exploitent la sortie de sshd -G, mettez-les à jour pour tolérer la casse mixte des directives. Si vous gérez des conteneurs ou des noyaux anciens dont le support de seccomp ou NO_NEW_PRIVS est incertain, testez la mise à jour en environnement de recette avant la production : un sshd qui refuse de démarrer sur un serveur distant sans accès de secours est le genre d'incident qui gâche une soirée. Et comme toujours sur une mise à jour de sshd en remote, gardez un accès hors bande ouvert (console, IPMI) pendant l'opération.

Notre lecture chez CZSyn

OpenSSH ne fait jamais la une pour une faille spectaculaire : c'est un projet qui avance par petites touches, correctif après correctif, et c'est précisément ce qui en fait un composant de confiance. Ce qui nous frappe dans la 10.4, c'est le changement de philosophie sur la tolérance aux pannes : le sandbox seccomp qui devient fatal plutôt que de logger et continuer, le protocole qui déconnecte plutôt que de tolérer un comportement limite. C'est le bon réflexe de sécurité, mais cela veut aussi dire que vous ne pouvez plus déployer une mise à jour majeure d'OpenSSH sans un passage en recette, même rapide, sur vos environnements les plus contraints (conteneurs minimalistes, noyaux anciens, appliances).

Le support post-quantique, encore expérimental et désactivé par défaut, est un signal à ne pas ignorer non plus. Il ne concerne aujourd'hui personne en production, mais les organisations soumises à des exigences de conformité renforcées ont intérêt à s'y familiariser en environnement de test dès maintenant. Pour la majorité des PME, la priorité reste plus simple : mettre à jour, vérifier vos scripts d'audit de configuration, et garder un accès de secours pendant l'opération.

Sources primaires

• OpenSSH.org, notes de version OpenSSH 10.4, 6 juillet 2026.
• Site officiel du projet, openssh.com.