Publication de la version OpenSSH 10.0

La version OpenSSH 10.0 a été publiée, une implémentation ouverte du client et du serveur pour travailler avec les protocoles SSH 2.0 et SFTP. Principales modifications :

  • La prise en charge des signatures numériques basées sur l'algorithme DSA a été supprimée, car son niveau de sécurité ne répond plus aux exigences modernes. Les coûts de maintien d'un algorithme DSA non sécurisé ne sont pas justifiés et sa suppression permettra de stimuler l'interruption de son soutien dans d'autres implémentations de SSH et bibliothèques cryptographiques. Par défaut, l'utilisation des clés DSA a été arrêtée en 2015.
  • La séparation de sshd en plusieurs fichiers exécutables distincts a été poursuivie. Dans OpenSSH 9.8, le processus sshd a été divisé en un processus sshd-session, exécutant des tâches liées à la gestion des sessions. Dans OpenSSH 10.0, le code d'authentification a été déplacé de sshd-session vers un processus distinct sshd-auth. Le processus sshd-auth permet d'isoler davantage les données d'authentification dans l'espace d'adressage d'un processus distinct, empêchant ainsi l'accès à ces données en mémoire lors d'attaques sur le code utilisé pour traiter les étapes de connexion jusqu'à la fin de l'authentification. De plus, ce changement réduit légèrement la consommation de mémoire, car le code d'authentification n'est présent en mémoire que pendant le processus d'authentification, puis est déchargé à la fin du processus sshd-auth.
  • Dans ssh, l'algorithme d'échange de clés hybrid « mlkem768x25519-sha256 », résistant aux attaques par ordinateur quantique, est utilisé par défaut et combine X25519 ECDH et l'algorithme ML-KEM (CRYSTALS-Kyber), standardisé par le National Institute of Standards and Technology (NIST) des États-Unis. ML-KEM utilise des méthodes cryptographiques basées sur des problèmes de théorie des réseaux, dont le temps de résolution n'est pas différent sur des ordinateurs classiques et quantiques.
  • Dans ssh_config, les directives SetEnv et User ont été mises à jour pour prendre en charge les substitutions de type « %-token » et l'expansion des variables d'environnement.
  • Dans ssh_config et sshd_config, le support de l'expression « Match version » a été ajouté, permettant d'appliquer des réglages en fonction de la version d'OpenSSH en cours, par exemple, pour se lier à OpenSSH 10, on peut spécifier « Match version OpenSSH_10.* ».
  • Un support pour les expressions a été ajouté dans ssh_config :
    • «Match sessiontype», permettant d'appliquer des paramètres en fonction du type de session demandé : «shell» pour les sessions interactives, «exec» pour l'exécution de commandes, «subsystem» pour sftp et «none» pour les tunnels et la redirection de trafic.
    • «Match command» pour lier des actions aux commandes spécifiées dans la ligne de commande pour exécution via ssh.
    • ‘Match tagged «»‘ et ‘Match command «»‘ pour lier à des tags vides et exécuter ssh sans spécifier de commande à exécuter.
  • Dans sshd_config, l'utilisation de masques dans les chemins de fichiers indiqués dans les directives AuthorizedKeysFile et AuthorizedPrincipalsFile est autorisée.
  • Le client ssh a ajouté la prise en charge de l'option «VersionAddendum» pour ajouter du texte arbitraire à la ligne de version (auparavant, cette option n'était disponible que pour de serveurs sshd).
  • Les outils scp et sftp prennent désormais en charge la configuration «ControlMaster no» pour interdire l'utilisation de connexions existantes lors de la reconnexion à un hôte.
  • Dans sshd, la prise en charge de l'implémentation de l'algorithme de Diffie-Hellman dans le champ final est désactivée par défaut, ce qui a entraîné la suppression des méthodes «diffie-hellman-group*» et «diffie-hellman-group-exchange-*» de la liste KEXAlgorithms. Par rapport à l'algorithme de Diffie-Hellman basé sur des courbes elliptiques, l'implémentation à distance est plus lente et nécessite des ressources de calcul supplémentaires pour un niveau de sécurité identique.
  • Dans ssh, lors du choix d'un chiffrement pour la connexion, le mode AES-GCM est désormais préféré à AES-CTR. Par défaut, une liste de priorités est définie pour le choix des chiffrements : Chacha20/Poly1305, AES-GCM (128/256) et AES-CTR (128/192/256).
  • Dans ssh-agent, la suppression de toutes les clés chargées est activée lors de la réception du signal SIGUSR1.
  • Dans ssh-keygen, la prise en charge des tokens FIDO, ne renvoyant pas de données d'attestation, telles que WinHello, a été ajoutée.
  • Dans ssh-agent, une option «-Owebsafe-allow=…» a été ajoutée pour redéfinir la liste blanche des applications FIDO.
  • Un utilitaire expérimental regress/misc/ssh-verify-attestation a été ajouté pour vérifier les données d'attestation FIDO, générées en option par ssh-keygen lors de l'enregistrement des clés FIDO.
  • Dans ssh-keygen, il est désormais possible d'utiliser «-» au lieu du nom de fichier.
  • Dans ssh-agent et la version portable d'OpenSSH, la prise en charge de l'activation par socket de style systemd a été mise en œuvre à l'aide du mécanisme LISTEN_PID/LISTEN_FDS.
  • Dans la version portable :
    • La prise en charge de la bibliothèque cryptographique AWS-LC (AWS libcrypto) a été mise en œuvre.
    • Dans sshd, la prise en charge de wtmpdb, équivalent de wtmp, qui n'est pas affecté par le problème de l'année 2038, a été ajoutée.
    • Une option « --with-linux-memlock-onfault » a été ajoutée à sshd pour verrouiller sshd en mémoire (interdisant le swap).
    • Une option « --with-security-key-standalone » a été ajoutée pour construire une bibliothèque autonome sk-libfido2.
    • Les paramètres de compilation pour RHEL 6 ont été supprimés de la spécification du paquet RPM.
  • Modification dans sshd concernant la sécurité : la directive DisableForwarding n'interdisait pas correctement le redirectionnement du protocole X11 et les appels à ssh-agent. Le redirectionnement X11 est désactivé par défaut côté serveur, et le redirectionnement ssh-agent côté client.

Source : opennet.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster