OpenSSH 10.4 est sorti le 6 juillet 2026 et 10.5 le 11 août 2026. Les deux atteignent déjà les serveurs via les mises à jour des distributions, et ils comportent trois changements que le projet lui-même signale comme potentiellement incompatibles. Ils méritent une lecture avant la mise à niveau, car lorsque sshd casse, le prix à payer est de ne pas pouvoir entrer pour le réparer.

Trois changements potentiellement incompatibles dans 10.4

  • Le mode de vidage de configuration utilise désormais des directives en casse mixte. sshd -T et ssh -G produisent PubkeyAuthentication plutôt que du tout-minuscule. Tout script qui vérifie la configuration avec sshd -T | grep pubkeyauthentication cessera silencieusement de correspondre : aucune erreur, juste un échec permanent, après quoi votre contrôle de conformité ou votre automatisation tire une conclusion fausse. Passer à grep -i suffit.
  • Sous Linux, l'échec du bac à sable seccomp devient fatal au lieu de permettre la poursuite du service. sshd se dégradait auparavant et continuait à servir quand le bac à sable ne s'initialisait pas ; désormais il s'arrête. Sur les noyaux anciens, les conteneurs restreints et certaines plateformes de virtualisation, cela signifie que sshd peut refuser de démarrer après la mise à niveau. La direction est bonne — un bac à sable silencieusement désactivé, c'est une hypothèse de sécurité qui n'existe plus — mais il faut le savoir avant, pas après.
  • Transport plus strict : les messages non-KEX pendant une renégociation post-authentification provoquent une déconnexion. Les clients bien élevés ne s'y heurtent pas, mais des bibliothèques anciennes, des outils de rebond et des sessions de longue durée peuvent tomber après un certain temps. Si les sessions se coupent au bout d'une ou deux heures après la mise à niveau, regardez ici d'abord.

10.4 apporte aussi trois correctifs de sécurité : manipulation par un serveur malveillant de l'emplacement de téléchargement en sftp, restrictions sur les transferts scp de distant à distant, et troncature des arguments de ligne de commande d'internal-sftp affectant les options de sécurité. Ce dernier mérite l'attention : si vous construisez des comptes SFTP restreints en passant des arguments à internal-sftp, la troncature signifie que des restrictions que vous croyiez appliquées n'ont peut-être jamais pris effet.

Ce qui change dans 10.5

10.5 ne comporte qu'un seul élément potentiellement incompatible : la version portable d'OpenSSH exige désormais le support ECC dans libcrypto, y compris la courbe NISTP521. Les paquets de distribution ne sont pas concernés ; si vous compilez contre un OpenSSL allégé, la compilation échoue franchement.

La nouveauté la plus utile est ssh -Z, qui affiche les clés essayées lors de l'authentification par clé publique, dans l'ordre. Cela répond directement à la forme la plus courante de Permission denied (publickey) : trop de clés locales, sept ou huit identités chargées dans ssh-agent, et le MaxAuthTries du serveur (6 par défaut) épuisé avant que la bonne clé n'ait son tour. Auparavant, il fallait compter l'ordre dans la sortie de ssh -vvv ; désormais une option l'affiche.

Le reste de 10.5 : ssh-keygen peut définir ou effacer les indicateurs touch-required et verify-required des clés FIDO ; l'authentification par certificat essaie d'abord les clés FIDO les moins contraignantes ; et sshd utilise setproctitle(3) pour identifier le moniteur post-authentification comme sshd-session, ce qui rend les listes de processus bien plus lisibles.

La discipline de mise à niveau de sshd (plus importante que le numéro de version)

  • Gardez toujours une session établie ouverte. Après la mise à niveau et le redémarrage de sshd, ouvrez une fenêtre entièrement nouvelle et reconnectez-vous ; ne fermez l'originale qu'une fois la nouvelle fonctionnelle. Les connexions existantes survivent au redémarrage de sshd : c'est votre corde de sécurité.
  • Vérifiez la syntaxe avant de redémarrer : sudo sshd -t. Pour lire la configuration effective, sudo sshd -T (en tenant compte du changement de casse ci-dessus).
  • Sur des conteneurs ou de vieux noyaux, vérifiez d'abord la disponibilité de seccomp, sinon vous heurterez de plein fouet le changement rendant l'échec fatal.
  • Connaissez à l'avance votre voie hors bande. La console VNC ou série de votre hébergeur et le mode rescue doivent être des choses que vous avez déjà utilisées une fois, pas que vous découvrez pendant une panne.

Si vous vous retrouvez vraiment enfermé dehors

Commencez par distinguer un problème de couche réseau d'un problème de service SSH : les deux mènent dans des directions totalement différentes. Impossible de vous connecter en SSH à votre VPS ? Une checklist pas à pas donne l'ordre complet — réseau local, pare-feu, port, puis état du service — tandis que que faire quand votre VPS ne répond pas (délai SSH dépassé) se concentre sur les symptômes de type timeout. Côté prévention — authentification par clé, règles ufw, utilité réelle d'un changement de port — voyez le durcissement d'un VPS : pare-feu ufw et connexion par clé SSH. Chaque instance SharkCloud est accessible depuis la console : même un sshd complètement mort n'impose pas de réinstaller le système.