Après six mois de développement libération , une implémentation client et serveur ouverte pour travailler via les protocoles SSH 2.0 et SFTP.
Une attention particulière dans la nouvelle version est l'élimination d'une vulnérabilité affectant ssh, sshd, ssh-add et ssh-keygen. Le problème est présent dans le code d'analyse des clés privées de type XMSS et permet à un attaquant de déclencher un débordement d'entier. La vulnérabilité est marquée comme exploitable, mais de peu d'utilité, puisque la prise en charge des clés XMSS est une fonctionnalité expérimentale désactivée par défaut (la version portable n'a même pas d'option de build dans autoconf pour activer XMSS).
Les principaux changements:
- En ssh, sshd et ssh-agent code qui empêche la récupération d'une clé privée située dans la RAM à la suite d'attaques par canal secondaire, telles que , и . Les clés privées sont désormais chiffrées lorsqu'elles sont chargées en mémoire et déchiffrées uniquement lorsqu'elles sont utilisées, restant chiffrées le reste du temps. Avec cette approche, pour réussir à récupérer la clé privée, l'attaquant doit d'abord récupérer une clé intermédiaire générée aléatoirement d'une taille de 16 Ko, utilisée pour chiffrer la clé principale, ce qui est peu probable étant donné le taux d'erreur de récupération typique des attaques modernes ;
- В Ajout d'un support expérimental pour un schéma simplifié de création et de vérification de signatures numériques. Les signatures numériques peuvent être créées à l'aide de clés SSH classiques stockées sur le disque ou dans l'agent ssh, et vérifiées à l'aide de quelque chose de similaire à authorised_keys. . Les informations sur l'espace de noms sont intégrées à la signature numérique pour éviter toute confusion lorsqu'elles sont utilisées dans différents domaines (par exemple, pour les e-mails et les fichiers) ;
- ssh-keygen a été commuté par défaut pour utiliser l'algorithme rsa-sha2-512 lors de la validation des certificats avec une signature numérique basée sur une clé RSA (lorsque vous travaillez en mode CA). De tels certificats ne sont pas compatibles avec les versions antérieures à OpenSSH 7.2 (pour garantir la compatibilité, le type d'algorithme doit être remplacé, par exemple en appelant "ssh-keygen -t ssh-rsa -s...") ;
- Dans ssh, l'expression ProxyCommand prend désormais en charge l'expansion de la substitution "%n" (le nom d'hôte spécifié dans la barre d'adresse) ;
- Dans les listes d'algorithmes de chiffrement pour ssh et sshd, vous pouvez désormais utiliser le caractère "^" pour insérer les algorithmes par défaut. Par exemple, pour ajouter ssh-ed25519 à la liste par défaut, vous pouvez spécifier « HostKeyAlgorithms ^ssh-ed25519 » ;
- ssh-keygen fournit la sortie d'un commentaire attaché à la clé lors de l'extraction d'une clé publique d'une clé privée ;
- Ajout de la possibilité d'utiliser l'indicateur « -v » dans ssh-keygen lors de l'exécution d'opérations de recherche de clé (par exemple, « ssh-keygen -vF host »), spécifiant ce qui aboutit à une signature visuelle de l'hôte ;
- Ajout de la possibilité d'utiliser comme format alternatif pour stocker les clés privées sur le disque. Le format PEM continue d'être utilisé par défaut et PKCS8 peut être utile pour assurer la compatibilité avec des applications tierces.
Source: opennet.ru