La version d'OpenSSH 8.8 a été publiée, une implémentation ouverte d'un client et d'un serveur pour travailler avec les protocoles SSH 2.0 et SFTP. La version se distingue par la désactivation par défaut de la possibilité d'utiliser des signatures numériques basées sur des clés RSA avec un hachage SHA-1 (« ssh-rsa »).
L'arrêt de la prise en charge des signatures « ssh-rsa » est dû à l'efficacité accrue des attaques par collision avec un préfixe donné (le coût de sélection d'une collision est estimé à environ 50 256 $). Pour tester l'utilisation de ssh-rsa sur vos systèmes, vous pouvez essayer de vous connecter via ssh avec l'option « -oHostKeyAlgorithms=-ssh-rsa ». La prise en charge des signatures RSA avec les hachages SHA-512 et SHA-2 (rsa-sha256-512/7.2), prises en charge depuis OpenSSH XNUMX, reste inchangée.
Dans la plupart des cas, l'arrêt de la prise en charge de « ssh-rsa » ne nécessitera aucune action manuelle de la part des utilisateurs, car OpenSSH avait auparavant le paramètre UpdateHostKeys activé par défaut, qui migre automatiquement les clients vers des algorithmes plus fiables. Pour la migration, l’extension du protocole «[email protected]", permettant au serveur, après authentification, d'informer le client de toutes les clés d'hôte disponibles. En cas de connexion à des hôtes avec de très anciennes versions d'OpenSSH côté client, vous pouvez restituer de manière sélective la possibilité d'utiliser les signatures « ssh-rsa » en ajoutant à ~/.ssh/config : Host old_hostname HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms + ssh-rsa
La nouvelle version résout également un problème de sécurité causé par sshd, à partir d'OpenSSH 6.2, qui n'initialisait pas correctement le groupe d'utilisateurs lors de l'exécution des commandes spécifiées dans les directives AuthorizedKeysCommand et AuthorizedPrincipalsCommand. Ces directives étaient censées permettre l'exécution de commandes sous un utilisateur différent, mais en fait elles ont hérité de la liste des groupes utilisés lors de l'exécution de sshd. Potentiellement, ce comportement, en présence de certains paramètres système, a permis au gestionnaire lancé d'obtenir des privilèges supplémentaires sur le système.
La nouvelle note de version inclut également un avertissement indiquant que scp utilisera par défaut SFTP au lieu de l'ancien protocole SCP/RCP. SFTP utilise des méthodes de gestion des noms plus prévisibles et n'utilise pas le traitement shell des modèles globaux dans les noms de fichiers du côté de l'autre hôte, ce qui crée des problèmes de sécurité. En particulier, lors de l'utilisation de SCP et RCP, le serveur décide quels fichiers et répertoires envoyer au client, et le client vérifie uniquement l'exactitude des noms d'objet renvoyés, ce qui, en l'absence de vérifications appropriées du côté client, permet le serveur pour transférer d'autres noms de fichiers différents de ceux demandés. Le protocole SFTP n'a pas ces problèmes, mais ne prend pas en charge l'extension de chemins spéciaux tels que « ~/ ». Pour remédier à cette différence, la version précédente d'OpenSSH a introduit une nouvelle extension du protocole SFTP aux chemins ~/ et ~user/ dans l'implémentation du serveur SFTP.
Source: opennet.ru