OpenSSH 7.9

Posté par (page perso) . Édité par Davy Defaud, palm123, theojouedubanjo et Benoît Sibaud. Modéré par ZeroHeure. Licence CC by-sa.
62
25
oct.
2018
Sécurité

OpenSSH 7.9 est disponible depuis le 19 octobre 2018. Ce projet, démarré par des développeurs d’OpenBSD, vise à proposer une alternative libre, sécurisée et moderne à des logiciels d’administration distante comme telnet et rlogin. Le but est d’ailleurs atteint, puisque ces deux derniers logiciels ont été relégués au rang d’antiquités depuis bien des années maintenant.

Logo d’OpenSSH

Vous trouverez en deuxième partie de cet article une sélection des changements apportés, reprenant grandement les notes de version.

Changements pouvant casser la compatibilité ascendante

Comme à chaque début de notes de version, les développeurs mettent en garde les utilisateurs à propos de changements qui pourraient poser problème sur des configurations existantes. Pour cette version, deux changements sont à surveiller de près :

  • l’utilisation de la nouvelle option CASignatureAlgorithms empêche l’utilisation des clefs DSA comme autorité de certification ;
  • dans sshd, le format du message de journal indiquant un succès ou un échec d’authentification a légèrement changé, incluant dorénavant l’empreinte du certificat (jusqu’alors il n’indiquait que l’identifiant de la clef et l’empreinte de la clef de l’autorité de certification).

Changements depuis OpenSSH 7.8

Nouvelles fonctionnalités

Parmi les nouveautés d’OpenSSH 7.9, on peut trouver :

  • ssh et sshd permettent maintenant de spécifier la plupart des ports en utilisant des noms de services, en utilisant les dénominations trouvables dans /etc/services (smtp au lieu de 25…) ;
  • dans ssh, il est dorénavant possible d’ajouter des directives de configuration IdentityAgent via des variables d’environnement, ce qui permet l’utilisation de multiples sockets d’agent sans utiliser des chemins en dur ;
  • ssh et ssh-keygen autorisent les listes de révocation de clefs (key revocation list, ou KRL) à spécifier des sommes de contrôles SHA-256 plutôt que les clefs publiques elles‐mêmes ;
  • d’ailleurs, dans la même thématique, ssh-keygen autorise la création de listes de révocation de clefs depuis une version encodée en base64 de l’empreinte SHA-256 desdites clefs ; en gros, l’idée est de pouvoir révoquer facilement une clef depuis l’information présente dans les journaux d’authentification de sshd.

Corrections de bogues

Cette nouvelle version apporte entre autres les corrections suivantes :

  • ssh et ssh-keygen évitent maintenant l’erreur « invalid format » quand ils tentent de charger une clef privée alors que la phrase de passe est incorrecte (bogue no 2901) ;
  • dans ssh, il est possible d’utiliser ForwardX11Timeout=0 pour désactiver le délai de grâce d’un forward X11 et pouvoir donc le faire indéfiniment ;
  • ssh va maintenant traiter les connexions ProxyJump de la même manière que les connexions ProxyCommand, par rapport la canonicalisation du nom d’hôte (ce qui veut dire que la canonicalisation ne sera pas effectuée, sauf si CanonicalizeHostname est paramétré à « always ») (bogue no 2896) ;
  • une régression introduite dans OpenSSH 7.8 au niveau de ssh a été corrigée, elle empêchait l’authentification par clef publique utilisant un certificat situé dans ssh-agent ou sshd de fonctionner sur une version d’OpenSSH inférieure à 7.8.

Portabilité

Il existe deux versions d’OpenSSH : une dédiée à OpenBSD et une deuxième contenant des correctifs de compatibilité pour les autres systèmes d’exploitation, appelée version portable.

Ces changements sont donc spécifiques à la version portable :

  • il est maintenant possible de compiler cette version d’OpenSSH en utilisant l’API openssl-1.1 (pour OpenSSL 1.1.0g et supérieur), l’API openssl-1.0 reste utilisable tant que l’équipe d’OpenSSL fournit des correctifs de sécurité pour cette version ;
  • l’appel système futex(2), situé dans le bac à sable seccomp de Linux est autorisé, car cela semble requis par certaines combinaisons glibc/OpenSSL ;
  • la fonction getgrouplist(3) avait une limite de nombre de groupes définie par une constante _SC_NGROUPS_MAX, ce n’est plus le cas maintenant ; certaines plates‐formes considéraient cette limite plutôt comme une recommandation.

Aller plus loin

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.