La version OpenSSH 8.8 est publiée, une implémentation open source du client et du serveur pour fonctionner avec les protocoles SSH 2.0 et SFTP. Cette version se distingue par la désactivation par défaut de l'utilisation de signatures numériques basées sur des clés RSA avec un hachage SHA-1 (« ssh-rsa »).
L'arrêt du support des signatures « ssh-rsa » est dû à l'augmentation de l'efficacité des attaques de collision avec préfixe fixe (le coût de la recherche d'une collision est estimé à environ 50 000 dollars). 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 ». Le support des signatures RSA avec des hachages SHA-256 et SHA-512 (rsa-sha2-256/512), qui sont pris en charge depuis OpenSSH 7.2, reste inchangé.
Dans la plupart des cas, l'arrêt du support de « ssh-rsa » ne nécessitera aucune action manuelle de la part des utilisateurs, car dans OpenSSH, la configuration UpdateHostKeys a été activée par défaut, assurant un passage automatique des clients vers des algorithmes plus fiables. Pour la migration, l'extension de protocole « hostkeys@openssh.com » est utilisée, permettant serveur d'informer le client de toutes les clés d'hôte disponibles après l'authentification. Dans le cas de connexions à des hôtes avec des versions très anciennes d'OpenSSH du côté client, il est possible de réactiver sélectivement l'utilisation des signatures « ssh-rsa » en ajoutant dans ~/.ssh/config: Host nom_de_l_hôte_ancien HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
La nouvelle version a également résolu un problème de sécurité causé par le fait qu'à partir de la version OpenSSH 6.2, l'initialisation du groupe utilisateur lors de l'exécution des commandes spécifiées dans les directives AuthorizedKeysCommand et AuthorizedPrincipalsCommand n'était pas correctement effectuée. Les directives mentionnées doivent permettre d'exécuter des commandes sous un autre utilisateur, mais en réalité, elles hérité de la liste des groupes utilisée lors du démarrage de sshd. Un tel comportement, en raison de certaines configurations système, permettait potentiellement au gestionnaire exécuté d'obtenir des privilèges supplémentaires dans le système.
Dans la note de la nouvelle version, un avertissement a également été publié concernant l'intention de passer par défaut l'utilitaire scp à l'utilisation de SFTP au lieu du protocole SCP/RCP obsolète. SFTP utilise des méthodes de traitement des noms plus prévisibles et n'applique pas le traitement des modèles globaux dans les noms de fichiers via le shell sur l'autre hôte, ce qui pose des problèmes de sécurité. En particulier, lors de l'utilisation de SCP et RCP serveur le serveur décide quels fichiers et répertoires envoyer au client, et le client ne vérifie que la validité des noms d'objets qui lui sont renvoyés, ce qui, en l'absence de vérifications adéquates du côté client, permet au serveur de transmettre d'autres noms de fichiers différents de ceux demandés. Le protocole SFTP est exempt des problèmes mentionnés, mais ne prend pas en charge la résolution des chemins spéciaux, tels que «~/». Pour résoudre cette différence, un nouvel ajout de protocole SFTP a été proposé dans la dernière version de OpenSSH pour la résolution des chemins ~/ et ~user/.
Source : opennet.ru
