{"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\/pl\/blog\/reliz-openssh-8-2-c-podderzhkoj-tokenov-dvuhfaktornoj-autentifikaczii-fido-u2f","title":{"rendered":"Release of OpenSSH 8.2 with support for FIDO\/U2F two-factor authentication tokens","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Po czterech miesi\u0105cach pracy zaprezentowano<\/a><\/noindex> wydanie OpenSSH 8.2<\/a><\/noindex>, otwart\u0105 implementacj\u0119 klienta i serwera do pracy z protoko\u0142ami SSH 2.0 i SFTP. <\/p>\n

Kluczowym ulepszeniem w wydaniu OpenSSH 8.2 by\u0142a mo\u017cliwo\u015b\u0107 wykorzystania uwierzytelniania dwuetapowego z u\u017cyciem urz\u0105dze\u0144 obs\u0142uguj\u0105cych protok\u00f3\u0142 U2F<\/a><\/noindex>, rozwijanym przez alianse FIDO<\/a><\/noindex>. U2F umo\u017cliwia tworzenie niedrogich token\u00f3w sprz\u0119towych do potwierdzania fizycznej obecno\u015bci u\u017cytkownika, z kt\u00f3rymi interakcja odbywa si\u0119 przez USB, Bluetooth lub NFC. Takie urz\u0105dzenia s\u0105 promowane jako \u015brodek dwuetapowego uwierzytelniania na stronach internetowych, s\u0105 ju\u017c obs\u0142ugiwane przez g\u0142\u00f3wne przegl\u0105darki i produkowane przez r\u00f3\u017cnych producent\u00f3w, w tym Yubico, Feitian, Thetis i Kensington.<\/p>\n

Aby wsp\u00f3\u0142pracowa\u0107 z urz\u0105dzeniami, kt\u00f3re potwierdzaj\u0105 obecno\u015b\u0107 u\u017cytkownika, w OpenSSH dodano nowe typy kluczy \u201eecdsa-sk\u201d i \u201eed25519-sk\u201d, w kt\u00f3rych wykorzystuje si\u0119 algorytmy podpisu cyfrowego ECDSA i Ed25519, w po\u0142\u0105czeniu z hashem SHA-256. Procedury interakcji z tokenami zosta\u0142y przeniesione do biblioteki po\u015bredniej, kt\u00f3ra jest \u0142adowana analogicznie jak biblioteka wspieraj\u0105ca PKCS#11 i jest owijkiem wok\u00f3\u0142 biblioteki. libfido2<\/a><\/noindex>, kt\u00f3ra zapewnia \u015brodki komunikacji z tokenami przez USB (obs\u0142ugiwane s\u0105 protoko\u0142y FIDO U2F\/CTAP 1 i FIDO 2.0\/CTAP 2). Opracowana przez deweloper\u00f3w OpenSSH po\u015brednia biblioteka libsk-libfido2 wliczona<\/a><\/noindex> jest cz\u0119\u015bci\u0105 libfido2, tak jak sterownik HID<\/a><\/noindex> dla OpenBSD.<\/p>\n

Aby uzyska\u0107 autoryzacj\u0119 i wygenerowa\u0107 klucz, nale\u017cy w ustawieniach wskaza\u0107 parametr \u201eSecurityKeyProvider\u201d lub ustawi\u0107 zmienn\u0105 \u015brodowiskow\u0105 SSH_SK_PROVIDER, podaj\u0105c \u015bcie\u017ck\u0119 do zewn\u0119trznej biblioteki libsk-libfido2.so (export SSH_SK_PROVIDER=\/path\/to\/libsk-libfido2.so). Mo\u017cliwa jest kompilacja openssh z wbudowanym wsparciem dla biblioteki-przeka\u017anika (\u2014with-security-key-builtin), w tym przypadku nale\u017cy ustawi\u0107 parametr \u201eSecurityKeyProvider=internal\u201d.
\nNast\u0119pnie nale\u017cy uruchomi\u0107 \u201essh-keygen -t ecdsa-sk\u201d lub, je\u015bli klucze zosta\u0142y ju\u017c utworzone i skonfigurowane, po\u0142\u0105czy\u0107 si\u0119 z serwerem za pomoc\u0105 \u201essh\u201d. Przy uruchamianiu ssh-keygen utworzona para kluczy zostanie zapisana w \u201e~\/.ssh\/id_ecdsa_sk\u201d i mo\u017ce by\u0107 u\u017cywana w podobny spos\u00f3b jak inne klucze. <\/p>\n

Publiczny klucz (id_ecdsa_sk.pub) nale\u017cy skopiowa\u0107 na serwer do pliku authorized_keys. Po stronie serwera sprawdzany jest tylko podpis cyfrowy, a interakcja z tokenami odbywa si\u0119 po stronie klienta (na serwerze nie trzeba instalowa\u0107 libsk-libfido2, ale serwer musi obs\u0142ugiwa\u0107 typ kluczy \u201eecdsa-sk\u201d). Wygenerowany klucz prywatny (id_ecdsa_sk) jest w zasadzie deskryptorem klucza, kt\u00f3ry tworzy rzeczywisty klucz tylko w po\u0142\u0105czeniu z sekretna sekwencj\u0105, przechowywan\u0105 po stronie tokena U2F. W przypadku przej\u0119cia klucza id_ecdsa_sk przez atakuj\u0105cego, do przej\u015bcia autoryzacji b\u0119dzie r\u00f3wnie\u017c potrzebny dost\u0119p do sprz\u0119towego tokena, bez kt\u00f3rego zapisany w pliku id_ecdsa_sk klucz prywatny jest bezu\u017cyteczny. <\/p>\n

Ponadto, domy\u015blnie podczas wykonywania jakichkolwiek operacji z kluczami (zar\u00f3wno przy generowaniu, jak i przy uwierzytelnianiu) wymagane jest lokalne potwierdzenie fizycznej obecno\u015bci u\u017cytkownika, na przyk\u0142ad poprzez dotkni\u0119cie czujnika na tokenie, co utrudnia przeprowadzanie zdalnych atak\u00f3w na systemy z pod\u0142\u0105czonym tokenem. Jako dodatkowa warstwa ochrony na etapie uruchamiania ssh-keygen mo\u017cna r\u00f3wnie\u017c ustawi\u0107 has\u0142o do pliku z kluczem. <\/p>\n

W nowej wersji OpenSSH og\u0142oszono r\u00f3wnie\u017c przysz\u0142e przeniesienie algorytm\u00f3w korzystaj\u0105cych z haszy SHA-1 do kategorii przestarza\u0142ych, w zwi\u0105zku z podwy\u017cszeniem<\/a><\/noindex> efektywno\u015bci\u0105 atak\u00f3w kolizyjnych z zadanym prefiksem (koszt znalezienia kolizji szacowany jest na oko\u0142o 45 tysi\u0119cy dolar\u00f3w). W jednym z nadchodz\u0105cych wyda\u0144 planowane jest domy\u015blne wy\u0142\u0105czenie mo\u017cliwo\u015bci u\u017cywania algorytmu podpisu cyfrowego z kluczem publicznym «ssh-rsa», kt\u00f3ry jest wymieniony w oryginalnym RFC dla protoko\u0142u SSH i wci\u0105\u017c jest powszechnie stosowany w praktyce (aby sprawdzi\u0107 zastosowanie ssh-rsa w swoich systemach, mo\u017cna spr\u00f3bowa\u0107 po\u0142\u0105czy\u0107 si\u0119 przez ssh z opcj\u0105 «-oHostKeyAlgorithms=-ssh-rsa»).<\/p>\n

Aby u\u0142atwi\u0107 przej\u015bcie na nowe algorytmy w OpenSSH, w jednym z nast\u0119pnych wyda\u0144 domy\u015blnie w\u0142\u0105czona zostanie opcja UpdateHostKeys, kt\u00f3ra automatycznie przeniesie klient\u00f3w na bardziej niezawodne algorytmy. W\u015br\u00f3d zalecanych algorytm\u00f3w do migracji wymienione s\u0105 rsa-sha2-256\/512 na podstawie RFC8332 RSA SHA-2 (wsparcie od OpenSSH 7.2 i u\u017cywane domy\u015blnie), ssh-ed25519 (wsparcie od OpenSSH 6.5) oraz ecdsa-sha2-nistp256\/384\/521 na podstawie RFC5656 ECDSA (wsparcie od OpenSSH 5.7).<\/p>\n

W wersji OpenSSH 8.2 mo\u017cliwo\u015b\u0107 \u0142\u0105czenia przy u\u017cyciu «ssh-rsa» pozostaje, jednak ten algorytm zosta\u0142 usuni\u0119ty z listy CASignatureAlgorithms, kt\u00f3ra definiuje algorytmy dozwolone do podpisu cyfrowego nowych certyfikat\u00f3w. Podobnie algorytm diffie-hellman-group14-sha1 zosta\u0142 usuni\u0119ty z domy\u015blnie wspieranych algorytm\u00f3w wymiany kluczy. Zauwa\u017cono, \u017ce stosowanie SHA-1 w certyfikatach wi\u0105\u017ce si\u0119 z dodatkowym ryzykiem, poniewa\u017c atakuj\u0105cy ma nieograniczony czas na znalezienie kolizji dla istniej\u0105cego certyfikatu, podczas gdy czas ataku na klucze hosta jest ograniczony czasem oczekiwania na po\u0142\u0105czenie (LoginGraceTime). <\/p>\n

Podczas wykonywania ssh-keygen teraz domy\u015blnie stosowany jest algorytm rsa-sha2-512, kt\u00f3ry jest wspierany od OpenSSH 7.2, co mo\u017ce stworzy\u0107 problemy z kompatybilno\u015bci\u0105 podczas pr\u00f3by przetwarzania certyfikat\u00f3w podpisanych w OpenSSH 8.2 na systemach z starszymi wersjami OpenSSH (aby obej\u015b\u0107 ten problem przy tworzeniu podpisu, mo\u017cna jawnie wskaza\u0107 «ssh-keygen -t ssh-rsa» lub u\u017cy\u0107 algorytm\u00f3w ecdsa-sha2-nistp256\/384\/521, wspieranych od OpenSSH 5.7).<\/p>\n

Inne zmiany:<\/p>\n