Ce que publie OpenSSH 10.6, et ce qu'elle ne dit pas
OpenSSH 10.6, et sa version portable 10.6p1 qu'utilisent les distributions Linux, a été publiée le 6 octobre 2026. Les notes de version annoncent « un certain nombre de correctifs de sécurité », plusieurs nouveautés et quelques corrections de bugs. Elles ne listent aucun identifiant CVE et ne parlent d'aucune exploitation en cours : ce guide s'en tient donc strictement à ce qu'elles écrivent.
L'équipe d'OpenSSH ajoute une précision qui compte pour qui administre un parc. Elle reçoit un grand nombre de signalements produits avec des outils d'IA, constate que plusieurs bugs ont été découverts indépendamment par des chercheurs différents, et en conclut que des attaquants peuvent les trouver aussi. Elle annonce donc des publications plus fréquentes, pour livrer les correctifs plus vite au lieu de les regrouper.
Pour une agence, la conséquence est concrète : la mise à jour d'OpenSSH n'est plus un événement annuel. Il vous faut une procédure qui se répète sans risque, serveur après serveur, et qui vous dit à chaque fois ce qui a réellement changé.
Les correctifs de sécurité de la 10.6, tels que listés
- sftp — le client valide plus strictement les chemins renvoyés par le serveur, pour qu'un serveur ne puisse pas faire écrire une copie récursive hors de son répertoire cible.
- GSSAPI —
sshdne conserve les identifiants GSSAPI qu'après une authentification réussie, et réinitialise l'état GSSAPI avant chaque tentative. - Compression — le codeur à dictionnaire LZ77 est désactivé, pour fermer un canal auxiliaire : du texte injecté dans un canal pouvait aider à deviner des secrets circulant dans un autre canal de la même session.
- Noms d'utilisateur —
sshrefuse les caractères$et\dans un nom saisi en ligne de commande, pour éviter une injection dans le shell viaProxyCommandouMatch exec. - Certificats —
ssh-keygengère correctement l'heure d'été lors de la conversion des dates ; l'erreur pouvait décaler d'une heure l'expiration d'un certificat. - Paquets compressés — un contenu compressé ne peut plus dépasser, une fois décompressé, la taille maximale d'un paquet.
- authorized_keys — le mot clé
restricts'applique désormais aussi au transfert de tunnels (PermitTunnel, désactivé par défaut). - Valeurs none — certaines options qui acceptent
none, dontAuthorizedPrincipalsFile, étaient lues comme un nom de fichier quand un blocMatchles redéfinissait.
Le numéro affiché ne dit pas si vous êtes corrigé
L'objection vient vite : aucune CVE dans les notes, aucune distribution stable ne livre la 10.6, et un redémarrage de sshd raté peut vous laisser dehors. Pourquoi s'en occuper maintenant ?
Parce que les distributions ne suivent pas les numéros de l'amont. Elles gardent la version d'OpenSSH de leur sortie et y reportent les correctifs. Ubuntu l'a fait : les paquets de sécurité publiés le 14 octobre 2026 pour les versions 22.04, 24.04 et 26.04 reprennent les huit correctifs listés plus haut, refus des $ et des \ compris, tout en restant en 8.9p1, 9.6p1 et 10.2p1. À l'inverse, au 22 octobre 2026, le suivi de sécurité de Debian marque encore ces mêmes points comme non corrigés sur Debian 12 et Debian 13, sans avis de sécurité publié ; seules les branches de développement forky et sid livrent la 10.6p1.
Un serveur Ubuntu à jour en 9.6p1 est donc mieux couvert, sur ces points précis, qu'un serveur Debian en 10.0p1. Ce que vous contrôlez, c'est le paquet installé et son journal des modifications. La procédure de contrôle et de rechargement, elle, sera la même pour chaque mise à jour à venir.
Ce que livrent les distributions au 22 octobre 2026
Faites défiler le tableau
| Distribution | Paquet OpenSSH | Correctifs de la 10.6 |
|---|---|---|
| Debian 12 (bookworm) | 1:9.2p1-2+deb12u10 | Non reportés selon le suivi Debian |
| Debian 13 (trixie) | 1:10.0p1-7+deb13u4 | Non reportés selon le suivi Debian |
| Debian forky et sid | 1:10.6p1-1 | Inclus (version amont 10.6p1) |
| Ubuntu 22.04 LTS | 1:8.9p1-3ubuntu0.18 | Reportés par la mise à jour de sécurité |
| Ubuntu 24.04 LTS | 1:9.6p1-3ubuntu13.20 | Reportés par la mise à jour de sécurité |
| Ubuntu 26.04 LTS | 1:10.2p1-2ubuntu3.8 | Reportés par la mise à jour de sécurité |
| AlmaLinux 8 | 8.0p1 | À vérifier dans les avis Red Hat et AlmaLinux |
| AlmaLinux 9 et 10 | 9.9p1 | À vérifier dans les avis Red Hat et AlmaLinux |
Inventorier la version réellement active
Lire la version du client
ssh -Vaffiche la version du client OpenSSH et celle de sa bibliothèque cryptographique, sur la sortie d'erreur. C'est le client qui applique le contrôle des noms d'utilisateur : sur un poste d'administration ou un bastion, c'est cette version qui compte.Lire la version du serveur
sudo /usr/sbin/sshd -Vaffiche la version du démon. L'option existe depuis OpenSSH 9.2 : sur un serveur plus ancien, comme AlmaLinux 8 en 8.0p1, elle n'est pas reconnue, et vous passez par le gestionnaire de paquets.Lire le paquet installé
Sur Debian et Ubuntu :
dpkg -s openssh-server | grep ^Version. Sur AlmaLinux et Rocky Linux :rpm -q openssh-server. Notez le numéro complet, suffixe de la distribution compris : c'est lui que vous comparez au tableau ci-dessus.Chercher les correctifs dans le journal du paquet
Sur Debian et Ubuntu :
apt changelog openssh-server | head -60. Sur AlmaLinux :rpm -q --changelog openssh-server | head -60. Sur Ubuntu, les entréesSECURITY UPDATEmentionnent par exemple « invalid chars in command-line username » ou « incorrect use of LZ77 dictionary coder ».Vérifier que le service a redémarré
Un paquet à jour ne protège rien si l'ancien démon tourne encore. Comparez
systemctl show -p ActiveEnterTimestamp ssh(le service s'appellesshdsur AlmaLinux) à la date d'installation du paquet.Balayer le parc en une commande
Listez vos serveurs dans
serveurs.txt, un par ligne, puis lancez :while read -r h; do printf '%s : ' "$h"; ssh -n -o BatchMode=yes "$h" 'dpkg -s openssh-server 2>/dev/null | grep ^Version || rpm -q openssh-server'; done < serveurs.txt. Le résultat tient en une ligne par serveur, à classer par famille de système.
Ce qui peut casser sur un parc d'administration
Les notes rangent trois points parmi les changements potentiellement incompatibles ; un seul touche vraiment vos scripts.
Le premier est le refus des $ et des \ dans un nom d'utilisateur saisi en ligne de commande, avec user@hôte comme avec -l. ssh s'arrête alors sur remote username contains invalid characters. Les cas réels : un compte de domaine de la forme DOMAINE\utilisateur, ou un script qui fabrique la commande ssh à partir d'une donnée externe. Un nom écrit en clair dans la directive User d'un bloc Host n'est pas soumis au contrôle ; le code source montre en revanche qu'un User construit avec des jetons % l'est. Dans un ProxyJump, le nom invalide d'un hôte de rebond est refusé avec invalid username.
Le deuxième est la compression : Compression yes reste accepté, mais compresse moins bien sans le dictionnaire LZ77. Rien ne casse ; un transfert sur un lien lent peut simplement durer plus longtemps. L'équipe d'OpenSSH recommande de compresser au niveau applicatif plutôt que dans SSH.
Le troisième, la désactivation de GatewayPorts et StreamLocalForwarding, ne concerne que de vieilles plateformes comme QNX 6 ou SCO OpenServer 5, pas vos serveurs Linux. S'y ajoutent deux effets visibles : scp -R affiche un avertissement de dépréciation, et sshd journalise par défaut, avec la nouvelle option WarnWeakCrypto, les clients qui négocient un échange de clés non résistant aux ordinateurs quantiques.
Changement, impact, action : le tableau de référence
Faites défiler le tableau
| Changement de la 10.6 | Impact sur un parc | Action |
|---|---|---|
| `$` et `\` refusés dans un nom saisi en ligne de commande | Scripts et comptes `DOMAINE\utilisateur` en échec | Écrire le nom en clair dans `User` d'un bloc `Host` |
| Dictionnaire LZ77 désactivé | `Compression yes` moins efficace | Compresser avant le transfert (`tar`, `rsync -z`) |
| Identifiants GSSAPI conservés après succès seulement | Aucun hors authentification Kerberos | Tester une connexion Kerberos après la mise à jour |
| `restrict` appliqué aux tunnels | Une clé `restrict` n'ouvre plus de tunnel | Recenser les clés de service qui reposent sur `PermitTunnel` |
| Valeurs `none` lues correctement dans `Match` | Un `AuthorizedPrincipalsFile none` désactive enfin l'option | Relire les blocs `Match` avec `sshd -T -C` |
| `scp -R` déprécié | Avertissement sur la sortie d'erreur | Retirer `-R` : la copie passe par la machine qui lance `scp` |
| `WarnWeakCrypto` actif côté serveur | Nouvelles lignes dans les journaux de `sshd` | Repérer les clients anciens à mettre à jour |
| Heure d'été corrigée dans `ssh-keygen` | Expirations de certificats auparavant décalées d'une heure | Contrôler les certificats émis près d'un changement d'heure |
Contrôler la configuration avant de recharger sshd
sshd -t vérifie la validité du fichier de configuration et des clés, sans rien démarrer. La page de manuel le recommande précisément pour mettre à jour sshd de façon fiable, les options de configuration pouvant changer d'une version à l'autre. Aucune sortie et un code de retour à 0 : le fichier est lisible.
sshd -T va plus loin : il affiche la configuration effective, valeurs par défaut comprises. C'est votre photographie avant et après. Pour vérifier un bloc Match, simulez une connexion avec -C, par exemple sudo sshd -T -C user=deploy,host=bastion.votre-domaine.com,addr=203.0.113.10. Les mots clés acceptés sont user, host, addr, laddr, lport et rdomain.
La commande de rechargement dépend de la famille : le service s'appelle ssh sur Debian et Ubuntu, sshd sur AlmaLinux et Rocky Linux. Les sessions déjà ouvertes survivent à un rechargement. Sur Ubuntu récent, ssh.socket écoute à la place du démon : un changement de Port demande systemctl daemon-reload, puis le redémarrage de ssh.socket.
Dérouler la mise à jour sans se couper l'accès
Garder une session de secours ouverte
Ouvrez une session SSH sur le serveur, passez root avec
sudo -i, et ne la fermez qu'à la toute fin. Si la nouvelle configuration refuse les connexions, c'est par elle que vous corrigez.Photographier la configuration effective
sudo sshd -T > /root/sshd-T-avant.txt. Ce fichier vous dira ce que la mise à jour a changé, valeur par valeur.Mettre à jour les paquets
Debian et Ubuntu :
sudo apt update && sudo apt install --only-upgrade openssh-server openssh-client. AlmaLinux et Rocky Linux :sudo dnf upgrade 'openssh*'.Tester la configuration
sudo sshd -t && echo OK. Si une ligne est refusée, corrigez-la avant toute autre action : un démon qui ne relit pas sa configuration ne démarrera pas non plus au prochain redémarrage du serveur.Recharger le service
sudo systemctl reload sshsur Debian et Ubuntu,sudo systemctl reload sshdsur AlmaLinux. Le paquet a souvent déjà relancé le service : le rechargement ne coûte rien et garantit que la configuration lue est la bonne.Ouvrir une nouvelle connexion depuis un autre terminal
ssh -v [email protected]. Connectez-vous réellement, avec la clé et l'utilisateur habituels. Tant que cette connexion n'a pas abouti, la session de secours reste ouverte.Comparer avant et après
sudo sshd -T | diff /root/sshd-T-avant.txt -. Une ligne inattendue se règle maintenant, pas le jour où un client appelle.Étendre au parc par vagues, via le bastion
Un serveur témoin par famille de système d'abord, le reste ensuite. Si vos accès passent par un bastion, mettez-le à jour en dernier, après avoir vérifié vos
ProxyJump: la mise en place est décrite dans notre guide du bastion SSH sur VPS.
Durcissement : une procédure, pas une checklist de plus
Ce guide ne refait pas le durcissement de sshd_config : PasswordAuthentication no, PermitRootLogin, AllowUsers ou AllowGroups et MaxAuthTries sont détaillés dans la checklist de durcissement pour agences et dans le durcissement initial d'un serveur Linux. Un point change cependant avec un sshd amont en 10.6 : la nouvelle option PubkeyOptions max-pk-ok laisse un client tester jusqu'à six clés publiques par défaut sans que ces essais comptent dans MaxAuthTries. Un MaxAuthTries bas cesse donc de rejeter l'administrateur qui a beaucoup de clés dans son agent.
Dépannage : les messages que vous risquez de voir
Les messages ci-dessous sont ceux du code source d'OpenSSH 10.6p1. Ils apparaissent dans le terminal pour le client, et dans le journal du service pour le serveur (journalctl -u ssh ou journalctl -u sshd). Lisez toujours le message complet avant d'agir : la plupart désignent la ligne fautive.
Messages d'erreur et remèdes
remote username contains invalid characters— le nom passé en ligne de commande contient$,\ou un autre caractère refusé ; écrivez le compte en clair dansUserd'un blocHost.Bad configuration option: AgentSocketPath— une option apparue en 10.6 a été copiée sur un serveur qui ne la connaît pas ; le message cite le fichier et la ligne, etsshds'arrête avecterminating, 1 bad configuration options.Missing privilege separation directory: /run/sshd—sshd -tlancé alors que le service est arrêté, sur Debian ou Ubuntu ; créez le répertoire avecsudo mkdir -p /run/sshd, puis relancez le test.warning: remote/remote -R copy mode is deprecated and will soon be removed— retirez-Rde vos scriptsscpavant qu'une prochaine version ne l'ignore.invalid username— un hôte de rebond deProxyJumpporte un nom refusé ; déplacez le nom dans un blocHostdédié au bastion.- Port modifié ignoré sur Ubuntu —
ssh.socketécoute toujours sur l'ancien port ; lancezsudo systemctl daemon-reload, puissudo systemctl restart ssh.socket.
Un parc homogène se met à jour avec une seule procédure
Ce qui rend une mise à jour d'OpenSSH risquée, ce n'est pas la version : c'est un parc où chaque serveur a sa propre histoire. Trois distributions, quatre manières de nommer le service, des scripts qui passent des noms d'utilisateur en ligne de commande : chaque écart devient une exception à traiter à la main, souvent un soir où un client attend.
Une agence qui tient dix ou cinquante serveurs a intérêt à réduire ces écarts. Une même famille de système, une même procédure de contrôle (sshd -t, sshd -T avant et après, session de secours), et un inventaire qui dit en une commande quel paquet tourne où. Sur ServOrbit.com, l'espace agence rassemble le portefeuille de vos clients — noms de domaine, comptes d'hébergement, VPS — et leurs échéances sur une seule plateforme. La procédure de mise à jour, elle, reste la vôtre : ce guide la décrit telle quelle, pour que vous la dérouliez sur chaque serveur.
