Version OpenSSH 8.0

Après cinq mois de développement soumis libération OpenSSH 8.0, une implémentation client et serveur ouverte pour travailler via les protocoles SSH 2.0 et SFTP.

Les principaux changements:

  • La prise en charge expérimentale d'une méthode d'échange de clés résistante aux attaques par force brute sur un ordinateur quantique a été ajoutée à ssh et sshd. Les ordinateurs quantiques sont radicalement plus rapides pour résoudre le problème de la décomposition d’un nombre naturel en facteurs premiers, qui est à la base des algorithmes de chiffrement asymétriques modernes et ne peut être résolu efficacement sur les processeurs classiques. La méthode proposée est basée sur l'algorithme NTRU Premier (fonction ntrup4591761), développée pour les cryptosystèmes post-quantiques, et la méthode d'échange de clés à courbe elliptique X25519 ;
  • Dans sshd, les directives ListenAddress et PermitOpen ne prennent plus en charge la syntaxe héritée « host/port », qui a été implémentée en 2001 comme alternative à « host:port » pour simplifier le travail avec IPv6. Dans les conditions modernes, la syntaxe « [::6]:1 » a été établie pour IPv22, et « hôte/port » est souvent confondu avec l'indication du sous-réseau (CIDR) ;
  • ssh, ssh-agent et ssh-add prennent désormais en charge les clés ECDSA dans les jetons PKCS#11 ;
  • Dans ssh-keygen, la taille de clé RSA par défaut a été augmentée à 3072 bits, conformément aux nouvelles recommandations du NIST ;
  • ssh permet l'utilisation du paramètre « PKCS11Provider=none » pour remplacer la directive PKCS11Provider spécifiée dans ssh_config ;
  • sshd fournit un affichage du journal des situations dans lesquelles la connexion est interrompue lors de la tentative d'exécution de commandes bloquées par la restriction « ForceCommand=internal-sftp » dans sshd_config ;
  • Dans ssh, lors de l'affichage d'une demande de confirmation d'acceptation d'une nouvelle clé d'hôte, au lieu de la réponse « oui », l'empreinte digitale correcte de la clé est désormais acceptée (en réponse à l'invitation à confirmer la connexion, l'utilisateur peut copier la hachage de référence reçu séparément via le presse-papiers, afin de ne pas le comparer manuellement) ;
  • ssh-keygen fournit une incrémentation automatique du numéro de séquence du certificat lors de la création de signatures numériques pour plusieurs certificats sur la ligne de commande ;
  • Une nouvelle option « -J » a été ajoutée à scp et sftp, équivalente au paramètre ProxyJump ;
  • Dans ssh-agent, ssh-pkcs11-helper et ssh-add, le traitement de l'option de ligne de commande « -v » a été ajouté pour augmenter le contenu informatif de la sortie (lorsqu'elle est spécifiée, cette option est transmise aux processus enfants, par exemple). exemple, lorsque ssh-pkcs11-helper est appelé depuis ssh-agent );
  • L'option « -T » a été ajoutée à ssh-add pour tester l'adéquation des clés dans ssh-agent pour effectuer des opérations de création et de vérification de signature numérique ;
  • sftp-server implémente la prise en charge de l'extension de protocole « lsetstat at openssh.com », qui ajoute la prise en charge de l'opération SSH2_FXP_SETSTAT pour SFTP, mais sans suivre de liens symboliques ;
  • Ajout de l'option "-h" à sftp pour exécuter les commandes chown/chgrp/chmod avec des requêtes qui n'utilisent pas de liens symboliques ;
  • sshd fournit le paramétrage de la variable d'environnement $SSH_CONNECTION pour PAM ;
  • Pour sshd, un mode de correspondance « Match final » a été ajouté à ssh_config, qui est similaire à « Match canonique », mais ne nécessite pas l'activation de la normalisation du nom d'hôte ;
  • Ajout de la prise en charge du préfixe '@' à sftp pour désactiver la traduction de la sortie des commandes exécutées en mode batch ;
  • Lorsque vous affichez le contenu d'un certificat à l'aide de la commande
    « ssh-keygen -Lf /path/certificate » affiche désormais l'algorithme utilisé par l'AC pour valider le certificat ;

  • Prise en charge améliorée de l'environnement Cygwin, par exemple en fournissant une comparaison insensible à la casse des noms de groupe et d'utilisateur. Le processus sshd dans le port Cygwin a été remplacé par cygsshd pour éviter les interférences avec le port OpenSSH fourni par Microsoft ;
  • Ajout de la possibilité de construire avec la branche expérimentale OpenSSL 3.x ;
  • Éliminé vulnérabilité (CVE-2019-6111) dans l'implémentation de l'utilitaire scp, qui permet d'écraser des fichiers arbitraires du répertoire cible côté client lors de l'accès à un serveur contrôlé par un attaquant. Le problème est que lors de l'utilisation de scp, le serveur décide quels fichiers et répertoires envoyer au client, et le client vérifie uniquement l'exactitude des noms d'objets renvoyés. La vérification côté client se limite au seul blocage des déplacements au-delà du répertoire courant (« ../ »), mais ne prend pas en compte le transfert de fichiers portant des noms différents de ceux initialement demandés. Dans le cas d'une copie récursive (-r), en plus des noms de fichiers, vous pouvez également manipuler les noms de sous-répertoires de la même manière. Par exemple, si l'utilisateur copie des fichiers dans le répertoire personnel, le serveur contrôlé par l'attaquant peut produire des fichiers portant les noms .bash_aliases ou .ssh/authorized_keys au lieu des fichiers demandés, et ils seront enregistrés par l'utilitaire scp dans le répertoire de l'utilisateur. répertoire personnel.

    Dans la nouvelle version, l'utilitaire scp a été mis à jour pour vérifier la correspondance entre les noms de fichiers demandés et ceux envoyés par le serveur, ce qui est effectué côté client. Cela peut entraîner des problèmes de traitement des masques, car les caractères d'extension de masque peuvent être traités différemment côté serveur et côté client. Dans le cas où de telles différences amènent le client à cesser d'accepter des fichiers dans scp, l'option « -T » a été ajoutée pour désactiver la vérification côté client. Pour corriger complètement le problème, une refonte conceptuelle du protocole scp est nécessaire, qui lui-même est déjà obsolète, il est donc recommandé d'utiliser à la place des protocoles plus modernes tels que sftp et rsync.

Source: opennet.ru

Ajouter un commentaire