Na die OpenSSH-kodebasis eksperimentele ondersteuning vir twee-faktor-verifikasie met behulp van toestelle wat die protokol ondersteun , ontwikkel deur die alliansie . U2F laat jou toe om laekoste hardeware tokens te skep om die fisiese teenwoordigheid van die gebruiker te bevestig, waarmee interaksie via USB, Bluetooth of NFC gemaak word. Hierdie toestelle word bevorder as 'n middel van twee-faktor-verifikasie op webwerwe, word reeds deur groot blaaiers ondersteun, en is beskikbaar by verskeie vervaardigers, insluitend Yubico, Feitian, Thetis en Kensington.
Om interaksie te hê met toestelle wat die teenwoordigheid van die gebruiker bevestig, is 'n nuwe tipe sleutels by OpenSSH gevoeg "[e-pos beskerm]” (“ecdsa-sk”), wat die ECDSA (Elliptic Curve Digital Signature Algorithm) digitale handtekeningalgoritme met NIST P-256 elliptiese kurwe en SHA-256 hash gebruik. Prosedures vir interaksie met tokens word in 'n intermediêre biblioteek geplaas, wat op 'n soortgelyke manier as die biblioteek vir PKCS#11-ondersteuning gelaai word en 'n omhulsel bo-op die biblioteek is , wat middele bied om met tokens oor USB te kommunikeer (ondersteun FIDO U2F/CTAP 1- en FIDO 2.0/CTAP 2-protokolle). Voorberei deur die OpenSSH-ontwikkelaars, die intermediêre biblioteek libsk-libfido2 in die hoofsamestelling van libfido2, soos vir OpenBSD.
Om U2F te aktiveer, kan jy 'n vars deel van die kodebasis van gebruik OpenSSH en die HOOF-tak van die biblioteek , wat reeds die laag insluit wat nodig is vir OpenSSH.
Libfido2 ondersteun OpenBSD, Linux, macOS en Windows.
Om 'n sleutel te verifieer en te genereer, moet jy die SSH_SK_PROVIDER omgewingsveranderlike stel, wat daarin die pad na libsk-libfido2.so aandui (uitvoer SSH_SK_PROVIDER=/path/to/libsk-libfido2.so), of die biblioteek definieer deur die SecurityKeyProvider instelling, en hardloop dan "ssh-keygen -t ecdsa-sk" of, as die sleutels reeds geskep en gekonfigureer is, koppel aan die bediener met "ssh". Wanneer jy ssh-keygen hardloop, sal die gegenereerde sleutelpaar in "~/.ssh/id_ecdsa_sk" gestoor word en kan op soortgelyke wyse as ander sleutels gebruik word.
Die publieke sleutel (id_ecdsa_sk.pub) moet na die bediener in die authorized_keys-lêer gekopieer word. Aan die bedienerkant word slegs die digitale handtekening geverifieer, en interaksie met tokens word aan die kliëntkant uitgevoer (jy hoef nie libsk-libfido2 op die bediener te installeer nie, maar die bediener moet die "ecdsa-sk" sleuteltipe ondersteun) . Die gegenereerde private sleutel (id_ecdsa_sk) is in wese 'n sleutelhandvatsel, wat slegs 'n regte sleutel vorm in kombinasie met die geheime volgorde wat op die U2F-tokenkant gestoor is.
As die id_ecdsa_sk-sleutel in die hande van 'n aanvaller val, sal hy ook toegang tot die hardewaretoken moet kry om verifikasie te slaag, waarsonder die private sleutel wat in die id_ecdsa_sk-lêer gestoor is nutteloos is. Daarbenewens word by verstek, wanneer enige bewerkings met sleutels uitgevoer word (beide tydens generering en tydens verifikasie), plaaslike bevestiging van die gebruiker se fisiese teenwoordigheid vereis, byvoorbeeld, word voorgestel om die sensor op die teken aan te raak, wat dit moeilik maak om voer afstandaanvalle uit op stelsels met 'n gekoppelde teken. As 'n ander lyn van verdediging, kan 'n wagwoord ook gespesifiseer word tydens die opstartfase van ssh-keygen om toegang tot die sleutellêer te verkry.
Die U2F-sleutel kan by ssh-agent gevoeg word via "ssh-add ~/.ssh/id_ecdsa_sk", maar ssh-agent moet gebou word met ondersteuning vir "ecdsa-sk" sleutels, die libsk-libfido2-laag moet teenwoordig wees en die agent moet loop op die stelsel waaraan die token gekoppel is.
’n Nuwe sleuteltipe “ecdsa-sk” is bygevoeg aangesien die formaat van OpenSSH ecdsa-sleutels verskil van die U2F-formaat vir ECDSA digitale handtekeninge in die teenwoordigheid van bykomende velde.
Bron: opennet.ru