Après quatre mois de développement libération , une implémentation client et serveur ouverte pour travailler via les protocoles SSH 2.0 et SFTP.
Une amélioration clé de la version d'OpenSSH 8.2 était la possibilité d'utiliser l'authentification à deux facteurs à l'aide d'appareils prenant en charge le protocole. , développé par l'alliance . U2F permet la création de jetons matériels à faible coût pour vérifier la présence physique de l'utilisateur, en interagissant avec lui via USB, Bluetooth ou NFC. De tels appareils sont présentés comme moyen d'authentification à deux facteurs sur les sites Web, sont déjà pris en charge par les principaux navigateurs et sont produits par divers fabricants, notamment Yubico, Feitian, Thetis et Kensington.
Pour interagir avec les appareils qui confirment la présence de l'utilisateur, de nouveaux types de clés « ecdsa-sk » et « ed25519-sk » ont été ajoutés à OpenSSH, qui utilisent les algorithmes de signature numérique ECDSA et Ed25519, combinés au hachage SHA-256. Les procédures d'interaction avec les jetons sont placées dans une bibliothèque intermédiaire, qui est chargée de la même manière que la bibliothèque pour la prise en charge de PKCS#11 et constitue un wrapper au-dessus de la bibliothèque. , qui fournit des outils pour communiquer avec des jetons via USB (les protocoles FIDO U2F/CTAP 1 et FIDO 2.0/CTAP 2 sont pris en charge). Bibliothèque intermédiaire libsk-libfido2 préparée par les développeurs OpenSSH dans le noyau libfido2, ainsi que pour OpenBSD.
Pour authentifier et générer une clé, vous devez spécifier le paramètre « SecurityKeyProvider » dans les paramètres ou définir la variable d'environnement SSH_SK_PROVIDER, en indiquant le chemin d'accès à la bibliothèque externe libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2. donc). Il est possible de construire openssh avec un support intégré pour la bibliothèque de couches (--with-security-key-builtin), dans ce cas, vous devez définir le paramètre « SecurityKeyProvider=internal ».
Ensuite, vous devez exécuter « ssh-keygen -t ecdsa-sk » ou, si les clés ont déjà été créées et configurées, vous connecter au serveur en utilisant « ssh ». Lorsque vous exécutez ssh-keygen, la paire de clés générée sera enregistrée dans « ~/.ssh/id_ecdsa_sk » et pourra être utilisée de la même manière que d'autres clés.
La clé publique (id_ecdsa_sk.pub) doit être copiée sur le serveur dans le fichierauthorized_keys. Côté serveur, seule la signature numérique est vérifiée et l'interaction avec les jetons est effectuée côté client (vous n'avez pas besoin d'installer libsk-libfido2 sur le serveur, mais le serveur doit prendre en charge le type de clé « ecdsa-sk ») . La clé privée générée (id_ecdsa_sk) est essentiellement un descripteur de clé, formant une véritable clé uniquement en combinaison avec la séquence secrète stockée du côté du jeton U2F. Si la clé id_ecdsa_sk tombe entre les mains d'un attaquant, pour passer l'authentification, il devra également accéder au jeton matériel, sans lequel la clé privée stockée dans le fichier id_ecdsa_sk est inutile.
De plus, par défaut, lors de toute opération avec des clés (aussi bien lors de la génération que lors de l'authentification), une confirmation locale de la présence physique de l'utilisateur est requise, par exemple, il est proposé de toucher le capteur du token, ce qui rend difficile la effectuer des attaques à distance sur des systèmes avec un token connecté. Comme autre ligne de défense, un mot de passe peut également être spécifié lors de la phase de démarrage de ssh-keygen pour accéder au fichier de clé.
La nouvelle version d'OpenSSH a également annoncé la dépréciation prochaine des algorithmes utilisant les hachages SHA-1 en raison de l'efficacité des attaques par collision avec un préfixe donné (le coût de sélection d'une collision est estimé à environ 45 mille dollars). Dans l'une des prochaines versions, ils prévoient de désactiver par défaut la possibilité d'utiliser l'algorithme de signature numérique à clé publique « ssh-rsa », qui est mentionné dans la RFC originale pour le protocole SSH et reste répandu dans la pratique (pour tester l'utilisation de ssh-rsa dans vos systèmes, vous pouvez essayer de vous connecter via ssh avec l'option « -oHostKeyAlgorithms=-ssh-rsa »).
Pour faciliter la transition vers de nouveaux algorithmes dans OpenSSH, dans une prochaine version, le paramètre UpdateHostKeys sera activé par défaut, ce qui migrera automatiquement les clients vers des algorithmes plus fiables. 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).
Dans OpenSSH 8.2, la possibilité de se connecter à l'aide de « ssh-rsa » est toujours disponible, mais cet algorithme a été supprimé de la liste CASignatureAlgorithms, qui définit les algorithmes autorisés pour signer numériquement de nouveaux certificats. De même, l'algorithme diffie-hellman-group14-sha1 a été supprimé des algorithmes d'échange de clés par défaut pris en charge. Il est à noter que l'utilisation de SHA-1 dans les certificats est associée à un risque supplémentaire, puisque l'attaquant dispose d'un temps illimité pour rechercher une collision pour un certificat existant, tandis que le temps d'attaque sur les clés de l'hôte est limité par le délai d'attente de connexion (LoginGraceTime ).
L'exécution de ssh-keygen utilise désormais par défaut l'algorithme rsa-sha2-512, qui est pris en charge depuis OpenSSH 7.2, ce qui peut créer des problèmes de compatibilité lors de la tentative de traitement de certificats signés dans OpenSSH 8.2 sur des systèmes exécutant des versions antérieures d'OpenSSH (pour contourner le problème lorsque générant une signature, vous pouvez spécifier explicitement « ssh-keygen -t ssh-rsa » ou utiliser les algorithmes ecdsa-sha2-nistp256/384/521, supportés depuis OpenSSH 5.7).
Autres changements :
- Une directive Include a été ajoutée à sshd_config, qui vous permet d'inclure le contenu d'autres fichiers à la position actuelle du fichier de configuration (des masques globaux peuvent être utilisés lors de la spécification du nom du fichier) ;
- L'option « no-touch-required » a été ajoutée à ssh-keygen, qui désactive la nécessité de confirmer physiquement l'accès au jeton lors de la génération de la clé ;
- Une directive PubkeyAuthOptions a été ajoutée à sshd_config, qui combine diverses options liées à l'authentification par clé publique. Actuellement, seul l'indicateur « no-touch-required » est pris en charge pour ignorer les contrôles de présence physique pour l'authentification par jeton. Par analogie, l'option « no-touch-required » a été ajoutée au fichier authorised_keys ;
- Ajout de l'option "-O write-attestation=/path" à ssh-keygen pour permettre l'écriture de certificats d'attestation FIDO supplémentaires lors de la génération de clés. OpenSSH n'utilise pas encore ces certificats, mais ils peuvent être utilisés ultérieurement pour vérifier que la clé est placée dans une quincaillerie de confiance ;
- Dans les paramètres ssh et sshd, il est désormais possible de paramétrer le mode de priorisation du trafic via la directive IPQoS (comportement par saut à moindre effort);
- Dans ssh, lors de la définition de la valeur « AddKeysToAgent=yes », si la clé ne contient pas de champ de commentaire, elle sera ajoutée à ssh-agent en indiquant le chemin d'accès à la clé sous forme de commentaire. DANS
ssh-keygen et ssh-agent utilisent également désormais les étiquettes PKCS#11 et le nom du sujet X.509 au lieu du chemin de la bibliothèque comme commentaires dans la clé ; - Ajout de la possibilité d'exporter des clés PEM pour DSA et ECDSA vers ssh-keygen ;
- Ajout d'un nouvel exécutable, ssh-sk-helper, utilisé pour isoler la bibliothèque d'accès aux jetons FIDO/U2F ;
- Ajout de l'option de construction « --with-zlib » à ssh et sshd pour la compilation avec le support de la bibliothèque zlib ;
- Conformément aux exigences de la RFC4253, un avertissement concernant le blocage d'accès dû au dépassement des limites MaxStartups est fourni dans la bannière affichée lors de la connexion. Pour simplifier les diagnostics, l'en-tête du processus sshd, visible lors de l'utilisation de l'utilitaire ps, affiche désormais le nombre de connexions actuellement authentifiées et l'état de la limite MaxStartups ;
- Dans ssh et ssh-agent, lors de l'appel d'un programme pour afficher une invitation à l'écran, spécifiée via $SSH_ASKPASS, un indicateur avec le type d'invitation est désormais transmis en plus : "confirmer" - boîte de dialogue de confirmation (oui/non), "aucun " - message d'information, "vierge" - demande de mot de passe ;
- Ajout d'une nouvelle opération de signatures numériques « find-principals » à ssh-keygen pour rechercher dans le fichier des signataires autorisés l'utilisateur associé à une signature numérique spécifiée ;
- Prise en charge améliorée de l'isolation des processus sshd sous Linux à l'aide du mécanisme seccomp : désactivation des appels système IPC, autorisation de clock_gettime64(), clock_nanosleep_time64 et clock_nanosleep().
Source: opennet.ru