Sortie d'OpenSSH 8.5

Après cinq mois de développement, OpenSSH 8.5, une implémentation ouverte du client et du serveur pour travailler avec les protocoles SSH 2.0 et SFTP, est maintenant disponible.

Les développeurs d'OpenSSH ont rappelé le prochain passage des algorithmes utilisant des hachages SHA-1 vers la catégorie des algorithmes obsolètes, en raison de l'augmentation de l'efficacité des attaques par collision avec un préfixe donné (le coût pour trouver une collision est estimé à environ 50 000 dollars). Dans l'un des prochains versions, ils prévoient de désactiver par défaut l'utilisation de l'algorithme de signature numérique à clé publique « ssh-rsa », qui est mentionné dans l'RFC original pour le protocole SSH et reste largement répandu dans la pratique.

Pour vérifier l'utilisation de ssh-rsa dans vos systèmes, vous pouvez essayer de vous connecter via ssh avec l'option « -oHostKeyAlgorithms=-ssh-rsa ». La désactivation par défaut des signatures numériques « ssh-rsa » ne signifie pas un abandon total de l'utilisation des clés RSA, car en plus de SHA-1, le protocole SSH permet l'utilisation d'autres algorithmes de hachage. En particulier, en plus de « ssh-rsa », il sera possible d'utiliser les paires « rsa-sha2-256 » (RSA/SHA256) et « rsa-sha2-512 » (RSA/SHA512).

Pour faciliter la transition vers de nouveaux algorithmes, OpenSSH 8.5 active par défaut le paramètre UpdateHostKeys, qui permet de transférer automatiquement les clients vers des algorithmes plus fiables. Grâce à ce paramètre, une extension spéciale du protocole « hostkeys@openssh.com » est activée, permettant au serveur d'informer le client de toutes les clés d'hôte disponibles après authentification. Le client peut enregistrer ces clés dans son fichier ~/.ssh/known_hosts, ce qui permet d'organiser la mise à jour des clés d'hôte et facilite le changement de clés sur le serveur.

L'utilisation des UpdateHostKeys est soumise à quelques réserves, qui peuvent être annulées à l'avenir : la clé doit être mentionnée dans le UserKnownHostsFile et ne doit pas figurer dans le GlobalKnownHostsFile ; la clé doit être présente sous un seul nom ; un certificat de clé d'hôte ne doit pas être utilisé ; aucun masque de nom d'hôte ne doit être appliqué dans known_hosts ; la configuration VerifyHostKeyDNS doit être désactivée ; l'option UserKnownHostsFile doit être activée.

Les algorithmes recommandés pour la migration incluent rsa-sha2-256/512 basé sur la RFC8332 RSA SHA-2 (supporté depuis OpenSSH 7.2 et utilisé par défaut), ssh-ed25519 (supporté depuis OpenSSH 6.5) et ecdsa-sha2-nistp256/384/521 basé sur la RFC5656 ECDSA (supporté depuis OpenSSH 5.7).

Autres changements :

• Modifications liées à la sécurité :
  • Une vulnérabilité causée par la libération répétée d'une mémoire déjà libérée (double-free) a été corrigée dans ssh-agent. Ce problème est apparu avec la version OpenSSH 8.2 et peut potentiellement être exploité si un attaquant a accès au socket ssh-agent sur le système local. L'exploitation de cette vulnérabilité est compliquée par le fait que seul l'utilisateur root et l'utilisateur d'origine ont accès au socket. Le scénario d'attaque le plus probable consiste à rediriger l'agent vers un compte contrôlé par l'attaquant ou vers un hôte où l'attaquant a un accès root.
  • Une protection contre la transmission de très grands paramètres avec des noms d'utilisateur a été ajoutée dans sshd, ce qui permet de bloquer les vulnérabilités dans les modules PAM (Pluggable Authentication Module). Par exemple, ce changement permet d'éviter que sshd soit utilisé comme vecteur pour exploiter une vulnérabilité récemment découverte dans Solaris (CVE-2020-14871).
• Modifications susceptibles de compromettre la compatibilité :
  • Dans ssh et sshd, une méthode expérimentale d'échange de clés, résistante à la recherche sur un ordinateur quantique, a été retravaillée. Les ordinateurs quantiques résolvent de manière radicalement plus rapide le problème de la décomposition d'un nombre naturel en facteurs premiers, qui est à la base des algorithmes de cryptage asymétriques modernes et est efficacement insoluble sur des processeurs classiques. La méthode utilisée est basée sur l'algorithme NTRU Prime, conçu pour les systèmes de cryptographie post-quantique, et sur la méthode d'échange de clés basée sur les courbes elliptiques X25519. Au lieu de sntrup4591761x25519-sha512@tinyssh.org, la méthode est désormais identifiée comme sntrup761x25519-sha512@openssh.com (l'algorithme sntrup4591761 a été remplacé par sntrup761).
  • Dans ssh et sshd, l'ordre d'annonce des algorithmes de signature numérique pris en charge a été modifié. ED25519 est désormais proposé en premier au lieu de ECDSA.
  • Dans ssh et sshd, la configuration des paramètres de qualité de service TOS/DSCP pour les sessions interactives est désormais effectuée avant l'établissement de la connexion TCP.
  • Dans ssh et sshd, le chiffrement rijndael-cbc@lysator.liu.se, identique à aes256-cbc et utilisé avant l'adoption de la RFC-4253, n'est plus supporté.
  • Par défaut, le paramètre CheckHostIP est désactivé, son utilité étant négligeable, mais son utilisation complique considérablement la rotation des clés pour les hôtes derrière des équilibreurs de charge.
• Dans sshd, les paramètres PerSourceMaxStartups et PerSourceNetBlockSize ont été ajoutés pour limiter l'intensité de démarrage des gestionnaires par adresse IP client. Ces paramètres permettent un contrôle plus précis des restrictions sur le démarrage des processus, par rapport à la configuration générale MaxStartups.
• Dans ssh et sshd, un nouveau paramètre LogVerbose a été ajouté, permettant d'augmenter de force le niveau des informations de débogage enregistrées, avec possibilité de filtrer par motifs, fonctions et fichiers.
• Dans ssh, lors de l'acceptation d'une nouvelle clé d'hôte, tous les noms d'hôtes et adresses IP, associés à la clé, sont affichés.
• Dans ssh, il est possible de spécifier l'option UserKnownHostsFile=none pour désactiver l'utilisation du fichier known_hosts lors de l'identification des clés d'hôtes.
• Dans ssh_config pour ssh, le paramètre KnownHostsCommand a été ajouté, permettant d'obtenir les données known_hosts à partir de la sortie d'une commande spécifiée.
• Dans ssh_config pour ssh, l'option PermitRemoteOpen a été ajoutée, permettant de restreindre le point de destination lors de l'utilisation de l'option RemoteForward avec SOCKS.
• Dans SSH, la clé FIDO demande à nouveau le code PIN en cas d'échec d'une opération de signature numérique à cause d'un code PIN incorrect et l'absence de demande de code PIN de l'utilisateur (par exemple, lorsque les données biométriques correctes n'ont pas pu être obtenues et que l'appareil est revenu à la saisie manuelle du code PIN).
• Dans sshd, le mécanisme d'isolation des processus basé sur seccomp-bpf pour la plateforme Linux a été amélioré avec la prise en charge d'appels système supplémentaires.
• L'outil contrib/ssh-copy-id a été mis à jour.

Source : opennet.ru