Apr\u00e8s quatre mois de d\u00e9veloppement, la version OpenSSH 8.7 est publi\u00e9e, une impl\u00e9mentation open source du client et serveur pour les protocoles SSH 2.0 et SFTP. <\/p>\n
Principales modifications : <\/p>\n
\n
Un mode exp\u00e9rimental de transfert de donn\u00e9es a \u00e9t\u00e9 ajout\u00e9 dans scp, utilisant le protocole SFTP au lieu du protocole traditionnel SCP\/RCP. SFTP applique des m\u00e9thodes de gestion des noms plus pr\u00e9visibles et ne fait pas appel \u00e0 un traitement de mod\u00e8les glob par le shell sur l'autre h\u00f4te, ce qui pose des probl\u00e8mes de s\u00e9curit\u00e9. Un drapeau '-s' a \u00e9t\u00e9 propos\u00e9 pour activer SFTP dans scp, mais une transition vers ce protocole par d\u00e9faut est pr\u00e9vue \u00e0 l'avenir.\n
Des extensions du protocole SFTP ont \u00e9t\u00e9 mises en \u0153uvre dans sftp-server pour r\u00e9v\u00e9ler les chemins ~\\\/ et ~user\\\/, ce qui est n\u00e9cessaire pour scp.\n
Le comportement de la commande scp a \u00e9t\u00e9 modifi\u00e9 lors de la copie de fichiers entre deux h\u00f4tes distants (par exemple, 'scp host-a:\/path host-b:'), qui se fait d\u00e9sormais par d\u00e9faut via un h\u00f4te local interm\u00e9diaire, comme si le drapeau '-3' \u00e9tait sp\u00e9cifi\u00e9. Cette approche permet d'\u00e9viter le transfert de donn\u00e9es d'identification superflues vers le premier h\u00f4te et l'interpr\u00e9tation triple des noms de fichiers dans le shell (c\u00f4t\u00e9 source, destination et syst\u00e8me local), et permet d'utiliser tous les m\u00e9thodes d'authentification avec SFTP pour acc\u00e9der aux h\u00f4tes distants, et non seulement les m\u00e9thodes non interactives. Une option '-R' a \u00e9t\u00e9 ajout\u00e9e pour restaurer l'ancien comportement.\n
Une configuration ForkAfterAuthentication a \u00e9t\u00e9 ajout\u00e9e dans ssh, correspondant au drapeau '-f'.\n
Une configuration StdinNull a \u00e9t\u00e9 ajout\u00e9e dans ssh, correspondant au drapeau '-n'.\n
Une configuration SessionType a \u00e9t\u00e9 ajout\u00e9e dans ssh, permettant de d\u00e9finir les modes correspondant aux drapeaux '-N' (sans session) et '-s' (sous-syst\u00e8me).\n
Dans ssh-keygen, il est d\u00e9sormais possible de sp\u00e9cifier la dur\u00e9e de validit\u00e9 des cl\u00e9s dans les fichiers de cl\u00e9s.\n
Un drapeau '-Oprint-pubkey' a \u00e9t\u00e9 ajout\u00e9 dans ssh-keygen pour afficher l'int\u00e9gralit\u00e9 de la cl\u00e9 publique dans la signature sshsig.\n
Dans ssh et sshd, tant le client que le serveur ont \u00e9t\u00e9 convertis pour utiliser un parseur de fichier de configuration plus strict, appliquant des r\u00e8gles similaires au shell pour le traitement des guillemets, des espaces et des caract\u00e8res d'\u00e9chappement. Le nouveau parseur ignore \u00e9galement les anciennes convictions telles que l'oubli d'arguments dans les options (par exemple, il n'est plus possible de laisser la directive DenyUsers vide), les guillemets non ferm\u00e9s, et la sp\u00e9cification de plusieurs symboles '='.\n
Lors de l'utilisation des enregistrements DNS SSHFP pour la v\u00e9rification des cl\u00e9s, ssh v\u00e9rifie d\u00e9sormais toutes les entr\u00e9es correspondantes, et non seulement celles contenant un type de signature num\u00e9rique sp\u00e9cifique.\n
Dans ssh-keygen, lors de la g\u00e9n\u00e9ration d'une cl\u00e9 FIDO avec l'option -Ochallenge pour le hachage, une couche int\u00e9gr\u00e9e est maintenant utilis\u00e9e au lieu des outils libfido2, ce qui permet d'utiliser des s\u00e9quences de challenge de taille sup\u00e9rieure ou inf\u00e9rieure \u00e0 32 octets.\n
Dans sshd, lors du traitement de la directive environment='\u2026' dans les fichiers authorized_keys, la premi\u00e8re correspondance est d\u00e9sormais accept\u00e9e et une limite de 1024 noms de variables d'environnement est en vigueur. <\/ul>\n
Les d\u00e9veloppeurs d'OpenSSH ont \u00e9galement averti que les algorithmes utilisant des hachages SHA-1 deviendraient obsol\u00e8tes, en raison de l'am\u00e9lioration de l'efficacit\u00e9 des attaques de collision avec pr\u00e9fixe d\u00e9fini (le co\u00fbt de la recherche de collision est estim\u00e9 \u00e0 environ 50 000 dollars). La prochaine version devrait d\u00e9sactiver par d\u00e9faut la possibilit\u00e9 d'utiliser l'algorithme de signature num\u00e9rique par cl\u00e9 publique \u00ab ssh-rsa \u00bb, qui est mentionn\u00e9 dans le RFC original du protocole SSH et reste largement utilis\u00e9 en pratique. <\/p>\n
Pour v\u00e9rifier l'utilisation de ssh-rsa dans vos syst\u00e8mes, vous pouvez essayer de vous connecter par ssh avec l'option \u00ab -oHostKeyAlgorithms=-ssh-rsa \u00bb. Cependant, la d\u00e9sactivation par d\u00e9faut des signatures num\u00e9riques \u00ab ssh-rsa \u00bb n'implique pas un abandon complet de l'utilisation des cl\u00e9s RSA, car, en plus de SHA-1, le protocole SSH permet d'utiliser d'autres algorithmes de hachage. En particulier, outre \u00ab ssh-rsa \u00bb, il sera possible d'utiliser les combinaisons \u00ab rsa-sha2-256 \u00bb (RSA\/SHA256) et \u00ab rsa-sha2-512 \u00bb (RSA\/SHA512). <\/p>\n