Au-delà de l'étiquette de version, OpenSSH 10.1 consolide le chemin commencé avec la série 10Migration vers la cryptographie post-quantique, modernisation de la qualité de service avec DSCP et renforcement des domaines historiquement sensibles (agents, clés, registres et analyse des paramètres). Vous trouverez ci-dessous un examen approfondi de toutes les nouvelles fonctionnalités (avec un contexte où cela ajoute de la valeur), ainsi que des lignes directrices pratiques pour les adopter sans surprises.
Voici la liste avec les Quoi de neuf dans cette version, également disponible dans le notes officielles.
Points forts et contexte de la publication
La version officielle d'OpenSSH 10.1 (06/10/2025) met en évidence trois axes : Sécurité préventive contre la cryptographie quantique, les réseaux DSCP et la désinfection des entrées. Il relie également des changements spécifiques ayant un impact opérationnel élevé : des routes de socket d'agent à nouveaux signes diagnostiques.
Un rappel clé du projet : Une future version ignorera les journaux SSHFP basés sur SHA‑1, pendant que ssh-keygen -r génère désormais des empreintes digitales SSHFP uniquement avec SHA‑256 par défaut, fermer la porte aux hachages faibles pour DNSSEC et la vérification de la clé d'hôte.
Avertissement concernant la cryptographie non post-quantique et nouvelle option WarnWeakCrypto
OpenSSH 10.1 introduit un avertissement lorsque la connexion négocie un échange de clés qui n'est pas résistant aux attaques post-quantiquesL’objectif est de se concentrer sur le risque du « stocker maintenant, décrypter plus tard » et d’accélérer la transition dans les environnements sensibles.
Ce comportement est contrôlé avec AvertissementWeakCrypto (A ssh_config), activée par défaut. Si vous effectuez une migration progressive ou conservez des hôtes hérités, Vous pouvez désactiver sélectivement l'avertissement avec des blocs Match. Par exemple :
Correspondance avec l'hôte unsafe.example.com WarnWeakCrypto non
Cryptographie et état de l'art : PQC, hybrides et SSHFP
Dans la version 10.0, le client est passé à l'utilisation par défaut mlkem768x25519‑sha256, un algorithme post-quantique hybride qui combine ML-KEM (KEM NIST FIPS 203) avec X25519. Cette stratégie hybride garantit que, même si une percée cryptanalytique devait émerger côté PQ, vous ne seriez pas plus mal loti qu'avec l'ECDH classique car le canal conserve la force de X25519.
Avec la 10.1, en plus de l'avertissement expliqué ci-dessus, la transition est renforcée : OpenSSH continuera à ignorer SSHFP avec SHA‑1 à l’avenir.; l'outil ssh-keygen émet déjà SSHFP avec SHA‑256 exclusivement. Sur le plan opérationnel, l'action recommandée est la suivante : régénérer et publier les empreintes digitales SSHFP en SHA‑256 pour vos hôtes.
Questions fréquemment posées : Pourquoi insister maintenant si les ordinateurs quantiques ne peuvent pas encore casser SSH ? Parce que les attaquants peuvent capturer aujourd'hui et déchiffrer demain. L'utilisation de KEX post-quantiques atténue déjà ce risque. Et si la jeunesse des algorithmes PQ vous inquiète, rappelez-vous ceci. la modalité hybride maintient le niveau de sécurité classique comme base.
Modernisation du réseau : DSCP/IPQoS et priorisation du trafic
Cette version consolide une refonte complète de la qualité de service. Sur le client comme sur le serveur, Le trafic interactif est par défaut de classe EF (Expedited Forwarding), ce qui contribue à réduire les latences sur le Wi-Fi et les médias encombrés. Le trafic non interactif passe à l'utilisation du marque DSCP par défaut du système, sans augmenter la priorité.
En pratique, les deux ssh(1) et sshd(8) changent dynamiquement la marque utilisée selon le type de canaux présents : si une même connexion combine une coque et une sftp, la phase de transfert non interactive utilisera la valeur non interactive pendant l'opération et reviendra à EF le moment venu. Ceci est contrôlé par la touche IPQoS en ssh_config y sshd_config.
En outre, La prise en charge des anciens ToS IPv4 est en cours de retrait dans l'option IPQoS (lowdelay, throughput, reliability cesser d'avoir effet). Si vous les utilisiez encore, migre vers la nomenclature DSCP (par exemple., ef, cs0, af11, Etc).
Renforcement des entrées : utilisateurs, URI et extensions
Dans la section sécurité, 10.1 corrige un cas subtil où, si vous construisiez des lignes de commande avec des données externes et utilisiez en même temps ProxyCommand avec extensions %r/%u, un attaquant pourrait introduire des expressions shell. Pour atténuer ce problème, ssh(1) interdit désormais les caractères de contrôle dans les utilisateurs transmis ou développés par CLI, et bloque également le caractère nul dans les URI ssh://.
Remarque sur la compatibilité : un point de validation a été assoupli pour éviter de casser des cas légitimes. Noms d'utilisateur littéraux définis dans les fichiers de configuration Les extensions (sans %) sont exemptées, à condition que la configuration locale soit considérée comme fiable.
Signaux et informations en direct : SIGINFO et visibilité
Un autre conseil pratique de débogage : ssh(1) et sshd(8) obtiennent des gestionnaires SIGINFO qui enregistrent l'état des canaux et sessions actifs. En production, ceci facilite les diagnostics de flux, le multiplexage, le transfert et le X11 sans avoir besoin d'attacher un débogueur ou d'augmenter de manière invasive la verbosité.
Dans le même esprit de transparence, lorsqu’une authentification par certificat échoue, sshd enregistre désormais suffisamment d'informations pour identifier le certificat (ainsi que la raison du refus). Si vous travaillez avec des certificats PKI et utilisateur/hôte, cette amélioration réduit considérablement les temps de résolution.
ssh-agent et clés : sockets, désinfection et PKCS#11
Pour empêcher l'accès croisé dans les environnements avec un montage restreint de /tmp, les sockets de l'agent (et ceux transmis par sshd) Je sais passer de /tmp à ~/.ssh/agent. Ainsi, un processus avec des autorisations limitées sur /tmp n'hérite plus accidentellement de la possibilité de signer avec vos clés de l'agent.
Ce changement a un autre dérivé : avant, le système d'exploitation pouvait nettoyer les sockets obsolètes, maintenant ssh-agent intègre son propre nettoyage à partir d'anciens sockets. De plus, l'agent ajoute de nouveaux indicateurs : -U y -u pour contrôler la propreté au démarrage, -uu pour ignorer le nom d'hôte lors du nettoyage, et -T pour forcer la localisation historique dans /tmp si tu en as vraiment besoin.
Dans le plan clé, le client et l'agent Les jetons ED25519 hébergés sur PKCS#11 sont désormais pris en chargeSi vous vous appuyez sur des HSM ou des clés cryptographiques, vous gagnerez en flexibilité sans sacrifier la solidité.
ssh-add et certificats : expiration autonettoyante
Lorsque vous ajoutez des certificats à l’agent, Son expiration est désormais fixée avec un délai de grâce de 5 minutesL’idée est simple : permettre aux transactions d’être complétées dans la file d’attente et ensuite, supprimer automatiquement le certificat de l'agent. Si votre flux exige un contrôle total, ssh‑add -N désactiver ce comportement.
RefuseConnection : déconnexions contrôlées côté client
Il existe des scénarios dans lesquels vous souhaitez interrompre une connexion depuis le client lui-même avec un message clair (par exemple, redirections opérationnelles ou avis d'obsolescence). OpenSSH 10.1 ajoute Refuser la connexion a ssh_config: si rencontré lors du traitement d'une section chaude, le client se termine avec une erreur et affiche le texte que vous avez défini.
Qualité du code et sécurité en direct
L'équipe continue de nettoyer la base de code. 10.1 listes fuites de mémoire corrigées, améliorations d'atomia lors de l'écriture known_hosts avec une forte affluence et plusieurs conditions de course résolues dans des processus tels que MaxStartups ou des sessions X11.
Une note de nettoyage de cryptographie : la prise en charge de XMSS est supprimée (expérimental et jamais par défaut). Préparer le terrain pour schémas de signature post-quantique des versions plus matures qui viendront dans les versions futures.
Portabilité et écosystème : PAM, FreeBSD, macOS, Android…
Les changements en matière de portabilité affectent de nombreux fronts : vérifications supplémentaires dans les environnements PAM (comme s'assurer que l'utilisateur ne change pas pendant le processus), améliorations de l'intégration avec FreeBSD (transfert de réglage et compatibilité), macOS (détection robuste des fonctions et des en-têtes) et Android (struct passwd avec des champs non nuls).
Des en-têtes de compatibilité sont également ajoutés pour les plates-formes sans certaines bibliothèques standard, réduisant ainsi le nombre de #ifdef dispersés. Enfin, ils sont raffinés politiques de sandbox seccomp sur Linux pour couvrir les appels système comme futex_time64 en 32 bits, et la prise en charge est ajoutée à AWS-LC comme alternative à OpenSSL/LibreSSL.
QoS en action : exemples pratiques et migration IPQoS
Si vous avez utilisé les anciens alias ToS (lowdelay, throughput...), maintenant ils seront ignorés et vous verrez un message de débogage suggérant DSCP. La migration typique consisterait à passer de IPQoS lowdelay a IPQoS ef pour des sessions interactives ; si vous utilisez également du SFTP lourd, vous pourriez définir les profils par Match en ssh_config/sshd_config pour séparer le trafic.
N'oubliez pas que le moteur sélectionne et met à jour automatiquement Il marque en temps réel en fonction des canaux ouverts, donc la plupart du travail est déjà effectué pour vous par OpenSSH.
Installation d'OpenSSH 10.1 sous Linux (source)
Alors que les distributions intègrent la version, vous pouvez compiler à partir de la source officielleTéléchargez l'archive tar à partir des miroirs du projet, décompressez-la et compilez :
tar -xvf ouvresh-10.1.tar.gz
Entrez dans le répertoire et configurer les préfixes et les itinéraires de configuration Si vous en avez besoin. Par exemple :
cd openssh-10.1 ./configure --prefix=/opt --sysconfdir=/etc/ssh
Compiler et installer comme d'habitude (en fonction des permissions, peut-être avec superutilisateur) :
à prendre une
make install
Activer OpenSSH sur Windows avec PowerShell
Dans les environnements Windows modernes (Server 2019/Windows 10 1809+), Vous pouvez installer le client et le serveur OpenSSH en tant que fonctionnalités système.. Vérifier les capacités et l'état :
Get-WindowsCapability-Online | Where-Nom de l'objet - comme « OpenSSH* »
Installer les composants selon vos besoins :
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Démarrer et activer le service serveur SSH, et vérifiez la règle de pare-feu entrant :
Démarrer-Service sshd Set-Service -Name sshd -StartupType 'Automatic' Get-NetFirewallRule -Name 'OpenSSH-Server-In-TCP' -ErrorAction SilentlyContinue
Pour vous connecter depuis un autre hôte Windows ou Linux, utilisez le client standard : ssh dominio\usuario@servidor. Lors du premier accès, accepte l'empreinte digitale de l'hôte et authentifiez-vous avec votre mot de passe.
Guide opérationnel : diagnostics et bonnes pratiques
Pour les environnements avec certificats utilisateur/hôte, profiter d'une journalisation améliorée des démentis dans sshd pour déboguer les autorités de certification et les extensions. Si une session se bloque ou si vous suspectez un multiplexage, lance SIGINFO au processus de listage des canaux actifs sans augmenter le niveau de journalisation global.
Si vous dépendez des agents, vérifiez où se trouvent actuellement les prises (~/.ssh/agent) Y activer le nettoyage automatique Dans votre modèle de déploiement. Sur les postes partagés ou NFS, pensez à utiliser l'indicateur d'agent pour définir les hachages de nom d'hôte dans le chemin d'accès, si nécessaire.
Corrections de bugs les plus pertinentes
Dans 10.1 ils sont résolus régressions mineures dans X11 lorsqu'il est combiné avec des atténuations de la fréquence cardiaque (ObscureKeystrokeTiming), un cas de La mauvaise comptabilité de MaxStartups qui pourraient inonder les créneaux horaires, et l'écriture de known_hosts maintenant c'est fait dans les opérations atomiques pour éviter les lignes entrelacées avec une forte concurrence.
D'autres correctifs améliorent diagnostic lors du chargement des clés, gestion des limites de taille de configuration (de 256 Ko à 4 Mo), sortie d'audit et cas particuliers dans les transferts locaux et les séquences de contrôle. De plus, les messages et la sortie de ssh -G y sshd -T.
Liste de contrôle de migration recommandée
Cette liste rapide Il comprend les tâches que le projet lui-même suggère et ce qui ressort des changements :
- Cripto: vérifiez que votre
KexAlgorithmspermet un PQ hybride et génère un nouveau SSHFP en SHA‑256 avecssh-keygen -r. - QoS: vérifier
IPQoSsur client/serveur ; migrer les ToS hérités vers DSCP ; exploiter EF pour les sessions interactives. - Agents: adapte les scripts et les variables aux sockets sous
~/.ssh/agent; valorise le nettoyage automatique par l'agent lui-même. - Grandes configurations:Si vous générez des configurations en masse, la limite monte jusqu'à 4 Mo ; appliquez-le judicieusement et contrôle la validation.
- Analyseurs: évitez de créer des lignes de commande à partir d'entrées non fiables ; utilisez
configlocaux avec des littéraux lorsque vous avez des cas étranges dans les noms d'utilisateur.
Ceux qui gèrent des flottes mixtes apprécieront que 10.1 presser la sécurité là où ça fait le moins mal (analyseurs, agents, avertissements) et en même temps améliorer l'expérience quotidienne (QoS dynamique, SIGINFO, journalisation des certificats). Si vous utilisiez déjà la version 10.0, la transition est simple ; si vous venez de la version 9.x, prenez le temps d'optimiser DSCP, de régénérer SSHFP en SHA‑256 et d'activer les KEX hybrides pour vous protéger des menaces quantiques sans compromettre les performances.
