Après quatre mois de développement la sortie , une mise en œuvre ouverte du client et du serveur pour travailler avec les protocoles SSH 2.0 et SFTP.
La principale amélioration dans la version OpenSSH 8.2 est la possibilité d'utiliser l'authentification à deux facteurs avec des appareils prenant en charge le protocole , développé par l'alliance . U2F permet de créer des jetons matériels peu coûteux pour confirmer la présence physique de l'utilisateur, dont l'interaction se fait via USB, Bluetooth ou NFC. De tels dispositifs sont promus comme moyen d'authentification à deux facteurs sur les sites, sont déjà pris en charge par les principaux navigateurs et sont fabriqués par divers producteurs, notamment Yubico, Feitian, Thetis et Kensington.
Pour interagir avec les appareils confirmant la présence de l'utilisateur, de nouveaux types de clés « ecdsa-sk » et « ed25519-sk » ont été ajoutés dans OpenSSH, utilisant les algorithmes de signature numérique ECDSA et Ed25519, combinés avec un hachage SHA-256. Les procédures d'interaction avec les jetons ont été extraites dans une bibliothèque intermédiaire, qui se charge de manière similaire à la bibliothèque prenant en charge PKCS#11 et fait office de couche sur la bibliothèque. , fournissant des moyens de communication avec les jetons via USB (prenant en charge les protocoles FIDO U2F/CTAP 1 et FIDO 2.0/CTAP 2). La bibliothèque intermédiaire libsk-libfido2 préparée par les développeurs d'OpenSSH est intégrée à la composition principale de libfido2, tout comme pour OpenBSD.
Pour l'authentification et la génération de clés, il est nécessaire de spécifier dans les paramètres le paramètre « SecurityKeyProvider » ou de définir la variable d'environnement SSH_SK_PROVIDER, en indiquant le chemin vers la bibliothèque externe libsk-libfido2.so (export SSH_SK_PROVIDER=/path/to/libsk-libfido2.so). Il est possible de construire openssh avec le support intégré de la bibliothèque de couche (—with-security-key-builtin), dans ce cas, il faut définir le paramètre « SecurityKeyProvider=internal ».
Ensuite, il faut lancer « ssh-keygen -t ecdsa-sk » ou, si les clés sont déjà créées et configurées, se connecter au serveur avec « ssh ». Lors de l'exécution de ssh-keygen, la paire de clés créée sera enregistrée dans « ~/.ssh/id_ecdsa_sk » et peut être utilisée de manière similaire à d'autres clés.
La clé publique (id_ecdsa_sk.pub) doit être copiée sur le serveur dans le fichier authorized_keys. Du côté du serveur, seule la signature numérique est vérifiée, tandis que l'interaction avec les jetons se fait du côté client (il n'est pas nécessaire d'installer libsk-libfido2 sur le serveur, mais le serveur doit prendre en charge le type de clés « ecdsa-sk »). La clé privée générée (id_ecdsa_sk) est en réalité un descripteur de clé, ne formant la vraie clé qu'en combinaison avec une séquence secrète, stockée sur le jeton U2F. Si la clé id_ecdsa_sk tombe entre les mains d'un attaquant, il lui faudra également accéder au jeton matériel, sans quoi la clé privée sauvegardée dans le fichier id_ecdsa_sk est inutilisable.
De plus, par défaut, toute opération avec des clés (que ce soit lors de la génération ou de l'authentification) nécessite une confirmation locale de la présence physique de l'utilisateur, par exemple, en touchant le capteur sur le jeton, ce qui complique les attaques à distance sur les systèmes avec un jeton connecté. Comme autre mesure de protection, lors du lancement de ssh-keygen, il peut également être demandé de définir un mot de passe pour accéder au fichier de clés.
La nouvelle version d'OpenSSH a également annoncé la future mise hors service des algorithmes utilisant des hachages SHA-1, en raison de de l'efficacité des attaques par collision avec un préfixe donné (le coût de la recherche d'une collision est évalué à environ 45 000 dollars). Dans l'une des prochaines versions, il est prévu de désactiver par défaut la possibilité d'utiliser l'algorithme de signature numérique à clé publique « ssh-rsa », qui est mentionné dans l'ancienne RFC pour le protocole SSH et reste largement utilisé dans la pratique (pour vérifier 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 les nouveaux algorithmes dans OpenSSH, l'une des prochaines versions inclura par défaut la configuration UpdateHostKeys, qui permettra de transférer automatiquement les clients vers des algorithmes plus fiables. Parmi les algorithmes recommandés pour la migration figurent rsa-sha2-256/512 basé sur la RFC8332 RSA SHA-2 (soutenu depuis OpenSSH 7.2 et utilisé par défaut), ssh-ed25519 (soutenu depuis OpenSSH 6.5) et ecdsa-sha2-nistp256/384/521 basé sur la RFC5656 ECDSA (soutenu depuis OpenSSH 5.7).
Dans la version OpenSSH 8.2, la possibilité de se connecter en utilisant « ssh-rsa » est pour l'instant maintenue, mais cet algorithme a été retiré de la liste CASignatureAlgorithms, qui définit les algorithmes autorisés pour la signature numérique de nouveaux certificats. De même, l'algorithme diffie-hellman-group14-sha1 a été retiré des algorithmes d'échange de clés pris en charge par défaut. Il est noté que l'utilisation de SHA-1 dans les certificats comporte un risque supplémentaire, car un attaquant dispose d'un temps illimité pour rechercher une collision pour un certificat existant, tandis que le temps d'attaque sur les clés hôtes est limité par le délai de connexion (LoginGraceTime).
Lors de l'exécution de ssh-keygen, l'algorithme rsa-sha2-512 est désormais utilisé par défaut, supporté à partir de OpenSSH 7.2, ce qui peut poser des problèmes de compatibilité lors du traitement de certificats signés par OpenSSH 8.2 sur des systèmes avec des versions anciennes d'OpenSSH (pour contourner ce problème lors de la génération de signature, vous pouvez explicitement spécifier « ssh-keygen -t ssh-rsa » ou utiliser les algorithmes ecdsa-sha2-nistp256/384/521, pris en charge depuis OpenSSH 5.7).
Autres changements :
- Une directive Include a été ajoutée à sshd_config, permettant d'inclure le contenu d'autres fichiers à la position actuelle du fichier de configuration (l'utilisation de motifs glob est autorisée lors de la spécification du nom de fichier);
- Une option « no-touch-required » a été ajoutée à ssh-keygen, désactivant la nécessité d'une confirmation physique pour accéder au token lors de la génération de la clé;
- Une directive PubkeyAuthOptions a été ajoutée à sshd_config, combinant différentes options liées à l'authentification par clé publique. À l'heure actuelle, seul le drapeau « no-touch-required » est pris en charge pour contourner la vérification de la présence physique lors de l'autorisation avec un token. Par analogie, l'option « no-touch-required » a été ajoutée au fichier authorized_keys;
- Une option « -O write-attestation=/path » a été ajoutée à ssh-keygen, permettant d'écrire des certificats d'attestation FIDO supplémentaires lors de la génération de clés. OpenSSH n'utilise pas encore ces certificats, mais ils pourraient être utilisés ultérieurement pour vérifier le placement de la clé dans un stockage matériel digne de confiance;
- Dans les configurations ssh et sshd, le mode de priorisation du trafic peut désormais être défini via la directive IPQoS. (Comportement de transit à faible 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 avec comme commentaire le chemin de la clé. Dans
ssh-keygen et ssh-agent, des étiquettes PKCS#11 et le nom du sujet X.509 sont désormais également utilisés comme commentaires dans la clé au lieu du chemin vers la bibliothèque; - Une fonctionnalité d'exportation PEM a été ajoutée à ssh-keygen pour les clés DSA et ECDSA;
- Un nouveau file exécutable ssh-sk-helper a été ajouté, utilisé pour isoler la bibliothèque d'accès aux tokens FIDO/U2F;
- Une option de compilation « —with-zlib » a été ajoutée à ssh et sshd pour compiler avec le support de la bibliothèque zlib;
- Conformément à l'exigence de RFC4253, le message affiché lors de la connexion contient un avertissement concernant le blocage d'accès dû au dépassement des limites MaxStartups. Pour faciliter le diagnostic, le nombre de connexions authentifiées actuellement actives et l'état de la limite MaxStartups sont affichés dans l'en-tête du processus sshd, visible lors de l'utilisation de l'outil ps.
- Dans ssh et ssh-agent, lors de l'appel du programme pour afficher l'invite définie via $SSH_ASKPASS, un indicateur est désormais transmis pour le type d'invite : « confirm » — boîte de dialogue de confirmation (oui/non), « none » — message d'information, « blank » — demande de mot de passe.
- Dans ssh-keygen, une nouvelle opération pour les signatures numériques « find-principals » a été ajoutée pour rechercher dans le fichier des signataires autorisés de l'utilisateur lié à la signature numérique spécifiée.
- Amélioration du support de l'isolation du processus sshd sur Linux grâce au mécanisme seccomp : les appels système IPC sont interdits, tandis que clock_gettime64(), clock_nanosleep_time64 et clock_nanosleep() sont autorisés.
Source : opennet.ru
