Après quatre mois de développement, la sortie d'OpenSSH 8.7, une implémentation ouverte d'un client et d'un serveur permettant de travailler sur les protocoles SSH 2.0 et SFTP, a été présentée.
Les principaux changements:
- Un mode de transfert de données expérimental a été ajouté à scp en utilisant le protocole SFTP au lieu du protocole SCP/RCP traditionnel. SFTP utilise des méthodes de gestion des noms plus prévisibles et n'utilise pas le traitement shell des modèles globaux du côté de l'autre hôte, ce qui crée des problèmes de sécurité. Pour activer SFTP dans scp, l'indicateur « -s » a été proposé, mais à l'avenir il est prévu de passer à ce protocole par défaut.
- sftp-server implémente des extensions au protocole SFTP pour étendre les chemins ~/ et ~user/, ce qui est nécessaire pour scp.
- L'utilitaire scp a modifié le comportement lors de la copie de fichiers entre deux hôtes distants (par exemple, "scp host-a:/path host-b:"), qui se fait désormais par défaut via un hôte local intermédiaire, comme lors de la spécification du " -Drapeau 3". Cette approche vous permet d'éviter de transmettre des informations d'identification inutiles au premier hôte et une triple interprétation des noms de fichiers dans le shell (côté source, destination et système local), et lors de l'utilisation de SFTP, elle vous permet d'utiliser toutes les méthodes d'authentification lors de l'accès à distance. des hôtes, et pas seulement des méthodes non interactives. L'option "-R" a été ajoutée pour restaurer l'ancien comportement.
- Ajout du paramètre ForkAfterAuthentication à ssh correspondant à l'indicateur "-f".
- Ajout du paramètre StdinNull à ssh, correspondant à l'indicateur "-n".
- Un paramètre SessionType a été ajouté à ssh, grâce auquel vous pouvez définir les modes correspondant aux indicateurs « -N » (pas de session) et « -s » (sous-système).
- ssh-keygen vous permet de spécifier un intervalle de validité de clé dans les fichiers de clés.
- Ajout de l'indicateur "-Oprint-pubkey" à ssh-keygen pour imprimer la clé publique complète dans le cadre de la signature sshsig.
- Dans ssh et sshd, le client et le serveur ont été déplacés pour utiliser un analyseur de fichiers de configuration plus restrictif qui utilise des règles de type shell pour gérer les guillemets, les espaces et les caractères d'échappement. Le nouvel analyseur n'ignore pas non plus les hypothèses formulées précédemment, telles que l'omission d'arguments dans les options (par exemple, la directive DenyUsers ne peut plus être laissée vide), les guillemets non fermés et la spécification de plusieurs caractères =.
- Lorsque vous utilisez des enregistrements DNS SSHFP lors de la vérification des clés, ssh vérifie désormais tous les enregistrements correspondants, et pas seulement ceux contenant un type spécifique de signature numérique.
- Dans ssh-keygen, lors de la génération d'une clé FIDO avec l'option -Ochallenge, la couche intégrée est désormais utilisée pour le hachage, plutôt que libfido2, qui permet l'utilisation de séquences de défi supérieures ou inférieures à 32 octets.
- Dans sshd, lors du traitement des directives environnement="..." dans les fichiersauthorized_keys, la première correspondance est désormais acceptée et il y a une limite de 1024 noms de variables d'environnement.
Les développeurs d'OpenSSH ont également mis en garde contre la décomposition des algorithmes utilisant les hachages SHA-1 en raison de 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 XNUMX dollars). Dans la prochaine version, nous prévoyons de désactiver par défaut la possibilité d'utiliser l'algorithme de signature numérique à clé publique « ssh-rsa », qui a été mentionné dans la RFC originale pour le protocole SSH et reste largement utilisé dans la pratique.
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 ». Dans le même temps, la désactivation par défaut des signatures numériques « ssh-rsa » ne signifie pas un abandon complet de l'utilisation des clés RSA, puisqu'en plus de SHA-1, le protocole SSH permet l'utilisation d'autres algorithmes de calcul de hachage. Notamment, en plus de « ssh-rsa », il restera possible d'utiliser les bundles « rsa-sha2-256 » (RSA/SHA256) et « rsa-sha2-512 » (RSA/SHA512).
Pour faciliter la transition vers de nouveaux algorithmes, OpenSSH avait auparavant le paramètre UpdateHostKeys activé par défaut, ce qui permet aux clients de passer automatiquement à des algorithmes plus fiables. En utilisant ce paramètre, une extension de protocole spéciale est activée "[email protected]", permettant au serveur, après authentification, d'informer le client de toutes les clés d'hôte disponibles. Le client peut refléter ces clés dans son fichier ~/.ssh/known_hosts, ce qui permet de mettre à jour les clés de l'hôte et facilite la modification des clés sur le serveur.
L'utilisation de UpdateHostKeys est limitée par plusieurs mises en garde qui pourraient être supprimées à l'avenir : la clé doit être référencée dans le UserKnownHostsFile et non utilisée dans le GlobalKnownHostsFile ; la clé doit être présente sous un seul nom ; un certificat de clé d'hôte ne doit pas être utilisé ; dans known_hosts, les masques par nom d'hôte ne doivent pas être utilisés ; le paramètre VerifyHostKeyDNS doit être désactivé ; Le paramètre UserKnownHostsFile doit être actif.
Les algorithmes recommandés pour la migration incluent rsa-sha2-256/512 basé sur RFC8332 RSA SHA-2 (pris en charge depuis OpenSSH 7.2 et utilisé par défaut), ssh-ed25519 (pris en charge depuis OpenSSH 6.5) et ecdsa-sha2-nistp256/384/521 basé sur sur RFC5656 ECDSA (pris en charge depuis OpenSSH 5.7).
Source: opennet.ru