Publication d'OpenSSH 8.7

Après quatre mois de développement, la version OpenSSH 8.7 est publiée, une implémentation open source du client et serveur pour les protocoles SSH 2.0 et SFTP.

Principales modifications :

• Un mode expérimental de transfert de données a été ajouté à scp, utilisant le protocole SFTP au lieu du protocole SCP/RCP traditionnel. SFTP utilise des méthodes de traitement des noms plus prévisibles et n'effectue pas de traitement des motifs globaux via le shell sur l'autre hôte, ce qui pose des problèmes de sécurité. Pour activer SFTP dans scp, un drapeau « -s » a été proposé, mais il est prévu de passer à ce protocole par défaut à l'avenir.
• Des extensions du protocole SFTP ont été mises en œuvre dans sftp-server pour révéler les chemins ~\/ et ~user\/, ce qui est nécessaire pour scp.
• Le comportement de l'outil scp a été modifié lors de la copie de fichiers entre deux hôtes distants (par exemple, « scp host-a:\/path host-b:\ »), qui se fait désormais par défaut via un hôte local intermédiaire, comme lors de l'utilisation du drapeau « -3 ». Cette approche permet d'éviter de transmettre des identifiants superflus au premier hôte et de tripler l'interprétation des noms de fichiers dans le shell (côté source, destination et système local), et permet également en utilisant SFTP d'utiliser toutes les méthodes d'authentification pour accéder aux hôtes distants, et pas seulement les méthodes non interactives. Pour restaurer le comportement précédent, une option « -R » a été ajoutée.
• Une nouvelle configuration ForkAfterAuthentication a été ajoutée à ssh, correspondant au drapeau « -f ».
• Une nouvelle configuration StdinNull a été ajoutée à ssh, correspondant au drapeau « -n ».
• Une nouvelle configuration SessionType a été ajoutée à ssh, permettant de définir des modes correspondant aux drapeaux « -N » (sans session) et « -s » (sous-système).
• Dans ssh-keygen, il est désormais possible de spécifier la durée de validité des clés dans les fichiers de clés.
• Un drapeau « -Oprint-pubkey » a été ajouté à ssh-keygen pour afficher la clé publique complète dans la signature sshsig.
• Dans ssh et sshd, tant le client que le serveur, un parseur de fichier de configuration plus strict a été mis en place, utilisant des règles de traitement des guillemets, des espaces et des caractères d'échappement similaires à celles du shell. Le nouveau parseur ne passe également plus sur les suppositions antérieures, telles que le passage d'arguments dans les options (par exemple, il n'est plus possible de laisser une directive DenyUsers vide), les guillemets non fermés et la spécification de plusieurs symboles « = ».
• Lors de l'utilisation des enregistrements DNS SSHFP pour la vérification des clés, ssh vérifie désormais toutes les entrées correspondantes, et non seulement celles contenant un type de signature numérique spécifique.
• Dans ssh-keygen, lors de la génération d'une clé FIDO avec l'option -Ochallenge pour le hachage, une couche intégrée est maintenant utilisée au lieu des outils libfido2, ce qui permet d'utiliser des séquences de challenge de taille supérieure ou inférieure à 32 octets.
• Dans sshd, lors du traitement de la directive environment="…" dans les fichiers authorized_keys, seule la première correspondance est prise en compte et une limite de 1024 noms de variables d'environnement est imposée.

Les développeurs d'OpenSSH ont également averti que les algorithmes utilisant les hachages SHA-1 sont passés au statut d'obsolète, en raison de l'augmentation de l'efficacité des attaques par collision avec préfixe (le coût de la recherche d'une collision est estimé à environ 50 000 dollars). La prochaine version prévoit de désactiver par défaut l'utilisation de l'algorithme de signature numérique par clé publique « ssh-rsa », qui est mentionné dans le RFC original pour le protocole SSH et reste largement utilisé en 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 les nouveaux algorithmes, OpenSSH avait précédemment activé par défaut la configuration UpdateHostKeys, qui permet de transférer automatiquement les clients vers des algorithmes plus sûrs. Avec cette configuration, une extension spéciale du protocole « hostkeys@openssh.com » est activée, permettant serveur d'informer le client sur toutes les clés d'hôte disponibles après l'authentification. Le client peut refléter 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).

Source : opennet.ru