{"id":42941,"date":"2020-02-17T14:41:56","date_gmt":"2020-02-17T11:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f"},"modified":"2020-02-17T14:41:56","modified_gmt":"2020-02-17T11:41:56","slug":"reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","title":{"rendered":"Publication de OpenSSH 8.2 avec prise en charge des jetons d'authentification \u00e0 deux facteurs FIDO\/U2F","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Apr\u00e8s quatre mois de d\u00e9veloppement pr\u00e9sent\u00e9<\/a><\/noindex> la sortie OpenSSH 8.2<\/a><\/noindex>, une mise en \u0153uvre ouverte du client et du serveur pour travailler avec les protocoles SSH 2.0 et SFTP. <\/p>\n

La principale am\u00e9lioration dans la version OpenSSH 8.2 est la possibilit\u00e9 d'utiliser l'authentification \u00e0 deux facteurs avec des appareils prenant en charge le protocole U2F<\/a><\/noindex>, d\u00e9velopp\u00e9 par l'alliance FIDO<\/a><\/noindex>. U2F permet de cr\u00e9er des jetons mat\u00e9riels peu co\u00fbteux pour confirmer la pr\u00e9sence physique de l'utilisateur, dont l'interaction se fait via USB, Bluetooth ou NFC. De tels dispositifs sont promus comme moyen d'authentification \u00e0 deux facteurs sur les sites, sont d\u00e9j\u00e0 pris en charge par les principaux navigateurs et sont fabriqu\u00e9s par divers producteurs, notamment Yubico, Feitian, Thetis et Kensington.<\/p>\n

Pour interagir avec des dispositifs qui confirment la pr\u00e9sence de l'utilisateur, OpenSSH a introduit de nouveaux types de cl\u00e9s \u00ab ecdsa-sk \u00bb et \u00ab ed25519-sk \u00bb, qui utilisent les algorithmes de signature num\u00e9rique ECDSA et Ed25519, combin\u00e9s avec le hachage SHA-256. Les proc\u00e9dures d'interaction avec les jetons ont \u00e9t\u00e9 extraites dans une biblioth\u00e8que interm\u00e9diaire, qui se charge de mani\u00e8re similaire \u00e0 la biblioth\u00e8que pour prendre en charge PKCS#11 et constitue une enveloppe autour de la biblioth\u00e8que libfido2<\/a><\/noindex>, 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\u00e8que interm\u00e9diaire libsk-libfido2 pr\u00e9par\u00e9e par les d\u00e9veloppeurs d'OpenSSH sont incluses.<\/a><\/noindex> est int\u00e9gr\u00e9e \u00e0 la composition principale de libfido2, tout comme le pilote HID<\/a><\/noindex> pour OpenBSD.<\/p>\n

Pour l'authentification et la g\u00e9n\u00e9ration de cl\u00e9, il est n\u00e9cessaire de sp\u00e9cifier dans les param\u00e8tres le param\u00e8tre \u00ab SecurityKeyProvider \u00bb ou de d\u00e9finir la variable d'environnement SSH_SK_PROVIDER en indiquant le chemin vers la biblioth\u00e8que externe libsk-libfido2.so (export SSH_SK_PROVIDER=\/path\/to\/libsk-libfido2.so). Il est possible de construire openssh avec un support int\u00e9gr\u00e9 pour la biblioth\u00e8que interm\u00e9diaire (--with-security-key-builtin), dans ce cas, il faut d\u00e9finir le param\u00e8tre \u00ab SecurityKeyProvider=internal \u00bb.
\nEnsuite, vous devez ex\u00e9cuter \u00ab ssh-keygen -t ecdsa-sk \u00bb ou, si les cl\u00e9s sont d\u00e9j\u00e0 cr\u00e9\u00e9es et configur\u00e9es, vous connecter au serveur \u00e0 l'aide de \u00ab ssh \u00bb. Lors de l'ex\u00e9cution de ssh-keygen, la paire de cl\u00e9s g\u00e9n\u00e9r\u00e9e sera enregistr\u00e9e dans \u00ab ~\/.ssh\/id_ecdsa_sk \u00bb et peut \u00eatre utilis\u00e9e de mani\u00e8re similaire aux autres cl\u00e9s. <\/p>\n

La cl\u00e9 publique (id_ecdsa_sk.pub) doit \u00eatre copi\u00e9e sur le serveur dans le fichier authorized_keys. Du c\u00f4t\u00e9 du serveur, seule la signature num\u00e9rique est v\u00e9rifi\u00e9e, tandis que l'interaction avec les jetons se fait du c\u00f4t\u00e9 client (il n'est pas n\u00e9cessaire d'installer libsk-libfido2 sur le serveur, mais le serveur doit prendre en charge les types de cl\u00e9s \u00ab ecdsa-sk \u00bb). La cl\u00e9 priv\u00e9e g\u00e9n\u00e9r\u00e9e (id_ecdsa_sk) est essentiellement un descripteur de la cl\u00e9, formant la cl\u00e9 r\u00e9elle uniquement en combinaison avec une s\u00e9quence secr\u00e8te, conserv\u00e9e du c\u00f4t\u00e9 du jeton U2F. Si la cl\u00e9 id_ecdsa_sk tombait entre les mains d'un attaquant, pour r\u00e9ussir l'authentification, il lui faudrait \u00e9galement acc\u00e9der au jeton mat\u00e9riel, sans lequel la cl\u00e9 priv\u00e9e enregistr\u00e9e dans le fichier id_ecdsa_sk serait inutile. <\/p>\n

De plus, par d\u00e9faut, toute op\u00e9ration avec des cl\u00e9s (que ce soit lors de la g\u00e9n\u00e9ration ou de l'authentification) n\u00e9cessite une confirmation locale de la pr\u00e9sence physique de l'utilisateur, par exemple, en touchant le capteur sur le jeton, ce qui complique les attaques \u00e0 distance sur les syst\u00e8mes avec un jeton connect\u00e9. Comme autre mesure de protection, lors du lancement de ssh-keygen, il peut \u00e9galement \u00eatre demand\u00e9 de d\u00e9finir un mot de passe pour acc\u00e9der au fichier de cl\u00e9s. <\/p>\n

La nouvelle version d'OpenSSH a \u00e9galement annonc\u00e9 la future mise hors service des algorithmes utilisant des hachages SHA-1, en raison de l'augmentation<\/a><\/noindex> l'efficacit\u00e9 des attaques par collision avec un pr\u00e9fixe donn\u00e9 (le co\u00fbt pour trouver une collision est estim\u00e9 \u00e0 environ 45 000 dollars). Dans un des prochains versions, il est pr\u00e9vu de d\u00e9sactiver par d\u00e9faut la possibilit\u00e9 d'utiliser l'algorithme de signature num\u00e9rique par cl\u00e9 publique \u00ab ssh-rsa \u00bb, qui est mentionn\u00e9 dans le RFC d'origine pour le protocole SSH et reste largement courant dans la pratique (pour v\u00e9rifier l'utilisation de ssh-rsa dans ses syst\u00e8mes, on peut essayer de se connecter par ssh avec l'option \u00ab -oHostKeyAlgorithms=-ssh-rsa \u00bb).<\/p>\n

Pour faciliter la transition vers les nouveaux algorithmes dans OpenSSH, l'une des prochaines versions inclura par d\u00e9faut la configuration UpdateHostKeys, qui permettra de transf\u00e9rer automatiquement les clients vers des algorithmes plus fiables. Parmi les algorithmes recommand\u00e9s pour la migration figurent rsa-sha2-256\/512 bas\u00e9 sur la RFC8332 RSA SHA-2 (soutenu depuis OpenSSH 7.2 et utilis\u00e9 par d\u00e9faut), ssh-ed25519 (soutenu depuis OpenSSH 6.5) et ecdsa-sha2-nistp256\/384\/521 bas\u00e9 sur la RFC5656 ECDSA (soutenu depuis OpenSSH 5.7).<\/p>\n

Dans la version OpenSSH 8.2, la possibilit\u00e9 de se connecter en utilisant \u00ab ssh-rsa \u00bb est toujours laiss\u00e9e, mais cet algorithme a \u00e9t\u00e9 retir\u00e9 de la liste CASignatureAlgorithms, qui d\u00e9termine les algorithmes acceptables pour la signature num\u00e9rique de nouveaux certificats. De m\u00eame, l'algorithme diffie-hellman-group14-sha1 a \u00e9t\u00e9 retir\u00e9 des algorithmes d'\u00e9change de cl\u00e9s pris en charge par d\u00e9faut. Il est not\u00e9 que l'utilisation de SHA-1 dans les certificats pr\u00e9sente un risque suppl\u00e9mentaire, car un attaquant a un temps illimit\u00e9 pour rechercher une collision avec un certificat existant, tandis que le temps d'attaque sur les cl\u00e9s h\u00f4tes est limit\u00e9 par le d\u00e9lai d'attente de connexion (LoginGraceTime). <\/p>\n

Lors de l'ex\u00e9cution de ssh-keygen, l'algorithme rsa-sha2-512 est d\u00e9sormais appliqu\u00e9 par d\u00e9faut, pris en charge depuis OpenSSH 7.2, ce qui peut poser des probl\u00e8mes de compatibilit\u00e9 lors de la tentative de traitement de certificats sign\u00e9s dans OpenSSH 8.2 sur des syst\u00e8mes avec d'anciennes versions d'OpenSSH (pour contourner le probl\u00e8me lors de la formation de la signature, vous pouvez explicitement indiquer \u00ab ssh-keygen -t ssh-rsa \u00bb ou utiliser des algorithmes ecdsa-sha2-nistp256\/384\/521, pris en charge depuis OpenSSH 5.7).<\/p>\n

Autres changements :<\/p>\n