Релиз на OpenSSH 8.2 с поддръжка на токени за двуфакторна автентикация FIDO/U2F

След четири месеца разработка представен релиз OpenSSH 8.2, открито изпълнение на клиент и сървър за работа по протоколите SSH 2.0 и SFTP.

Ключовото подобрение в версията OpenSSH 8.2 е възможността за използване на двуфакторна автентикация чрез устройства, които поддържат протокола U2F, развиван от алианса FIDO. U2F позволява създаването на евтини хардуерни токени за потвърждаване на физическото присъствие на потребителя, с взаимодействие чрез USB, Bluetooth или NFC. Подобни устройства се предлагат като средство за двуфакторна автентификация на сайтове, вече са поддържани от основните браузъри и се произвеждат от различни производители, включително Yubico, Feitian, Thetis и Kensington.

За взаимодействие с устройствата, потвърждаващи присъствието на потребителя, в OpenSSH са добавени нови типове ключове «ecdsa-sk» и «ed25519-sk», прилагани с алгоритмите за цифрова подпись ECDSA и Ed25519, в съчетание с хеша SHA-256. Процедурите за взаимодействие с токените са отделени в междинна библиотека, която се зарежда подобно на библиотеката за поддръжка на PKCS#11 и представлява обвивка над библиотеката. libfido2, предоставяща средства за комуникация с токени чрез USB (поддържат се протоколите FIDO U2F/CTAP 1 и FIDO 2.0/CTAP 2). Подготвената от разработчиците на OpenSSH междинна библиотека libsk-libfido2 включена е основна част от libfido2, както и HID-драйвер за OpenBSD.

За автентикация и генериране на ключ е необходимо да се зададе параметърът «SecurityKeyProvider» в настройките или да се зададе променлива на средата SSH_SK_PROVIDER, указвайки пътя към външната библиотека libsk-libfido2.so (export SSH_SK_PROVIDER=\/path\/to\/libsk-libfido2.so). Възможно е изграждане на openssh със вградена поддръжка на библиотеката-обвивка (—with-security-key-builtin), в този случай е необходимо да се зададе параметърът «SecurityKeyProvider=internal».
След това трябва да стартирате «ssh-keygen -t ecdsa-sk» или, ако ключовете вече са създадени и конфигурирани, да се свържете със сървъра чрез «ssh». При стартиране на ssh-keygen, създадената двойка ключове ще бъде запазена в «~\/ .ssh\/id_ecdsa_sk» и може да се използва подобно на другите ключове.

Публичният ключ (id_ecdsa_sk.pub) трябва да бъде копиран на сървъра в файл authorized_keys. На страната на сървъра се проверява само цифровата подпис, а взаимодействието с токените се извършва на страната на клиента (не е необходимо да се инсталира libsk-libfido2 на сървъра, но сървърът трябва да поддържа тип ключове «ecdsa-sk»). Генерираният частен ключ (id_ecdsa_sk) по същество е дескриптор на ключа, който образува реалния ключ само в комбинация с тайна последователност, съхранявана на страната на токена U2F. В случай че ключът id_ecdsa_sk попадне в ръцете на нападател, за да премине автентикация, му е необходим достъп до хардуерния токен, без който съхраненият в файл id_ecdsa_sk частен ключ е безполезен.

Освен това, по подразбиране при изпълнение на всякакви операции с ключове (както при генериране, така и при удостоверяване) е необходимо локално потвърждение на физическото присъствие на потребителя, например, предлагайки да се докосне сензора на токена, което затруднява провеждането на дистанционни атаки на системи с включен токен. Като още едно ниво на защита по време на стартиране, на ssh-keygen може също да бъде зададена парола за достъп до файла с ключа.

В новата версия на OpenSSH също е обявено за предстоящо превеждане на алгоритми, използващи хешове SHA-1, в категорията на остарели. повишаването ефективността на колизионните атаки с зададен префикс (цената за подбора на колизия се оценява приблизително на 45 хиляди долара). В едно от следващите издания планират да деактивират по подразбиране възможността за използване на алгоритъма за цифрови подписи с открит ключ «ssh-rsa», който се споменава в оригиналния RFC за протокола SSH и остава широко разпространен на практика (за проверка на приложението на ssh-rsa в своите системи може да опитате да се свържете по ssh с опция «-oHostKeyAlgorithms=-ssh-rsa»).

За улесняване на прехода към новите алгоритми в OpenSSH, в един от следващите версии по подразбиране ще бъде активирана настройката UpdateHostKeys, която ще позволи автоматично прехвърляне на клиентите към по-надеждни алгоритми. Препоръчваните алгоритми за миграция включват rsa-sha2-256/512 на базата на RFC8332 RSA SHA-2 (поддържа се от OpenSSH 7.2 и се използва по подразбиране), ssh-ed25519 (поддържа се от OpenSSH 6.5) и ecdsa-sha2-nistp256/384/521 на базата на RFC5656 ECDSA (поддържа се от OpenSSH 5.7).

В версията OpenSSH 8.2 възможността за свързване с използване на „ssh-rsa“ все още е запазена, но този алгоритъм е премахнат от списъка CASignatureAlgorithms, определящ алгоритмите, допустими за цифрова подписка на нови сертификати. По същия начин алгритъмът diffie-hellman-group14-sha1 е премахнат от поддържаните по подразбиране алгоритми за обмен на ключове. Отбелязва се, че използването на SHA-1 в сертификатите носи допълнителен риск, тъй като атакуващият има неограничено време за търсене на колизия за съществуващ сертификат, докато времето на атака върху ключовете на хоста е ограничено от таймаута за свързване (LoginGraceTime).

При изпълнение на ssh-keygen сега по подразбиране се прилага алгоритъм rsa-sha2-512, който се поддържа от OpenSSH 7.2, което може да създаде проблеми със съвместимостта при опит за обработка на сертификати, удостоверени в OpenSSH 8.2, на системи със стари версии на OpenSSH (заобикаляне на проблема при формироването на подпис от конкретно указване на „ssh-keygen -t ssh-rsa“ или използване на алгоритми ecdsa-sha2-nistp256/384/521, поддържани от OpenSSH 5.7).

Други промени:

• В sshd_config е добавена директива Include, която позволява вмъкване на съдържанието на други файлове в текущата позиция на конфигурационния файл (при задаване на името на файла е позволено използването на glob-маски);
• В ssh-keygen е добавена опция „no-touch-required“, която деактивира необходимостта от физическо потвърждение на достъпа до токена при генериране на ключ;
• В sshd_config е добавена директива PubkeyAuthOptions, обединяваща различни опции, свързани с удостоверяване по открыти ключове. В момента се поддържа само флагът „no-touch-required“ за пропускане на проверката на физическото присъствие при удостоверяване с токен. По аналогия в файла authorized_keys е добавена опция „no-touch-required“.
• В ssh-keygen е добавена опция «-O write-attestation=\/path», която позволява записването на допълнителни атестационни сертификати FIDO при генерирането на ключове. OpenSSH в момента не използва тези сертификати, но те може да бъдат използвани за проверка на разположението на ключа в доверено хардуерно хранилище;
• В настройките на ssh и sshd чрез директивата IPQoS сега е възможно задаването на режим за приоритизация на трафика LE DSCP (Lower-Effort Per-Hop Behavior);
• В ssh при задаване на стойността «AddKeysToAgent=yes», ако ключът не съдържа поле с коментар, той ще бъде добавен в ssh-agent с указание за коментар, който е пътят към ключа. В
  ssh-keygen и ssh-agent вече използват етикети PKCS#11 и името на субекта X.509 вместо пътя към библиотеката като коментари в ключа;
• В ssh-keygen е добавена възможността за експортиране на PEM за ключове DSA и ECDSA;
• Добавен е нов изпълним файл ssh-sk-helper, използван за изолиране на библиотеката за достъп до токени FIDO\/U2F;
• В ssh и sshd е добавена опция за сборка «—with-zlib» за компилация с поддръжка на библиотеката zlib;
• В съответствие с изискванията на RFC4253 на показвания при свързване банер е осигурено показването на предупреждение за блокиране на достъпа поради превишаване на лимитите MaxStartups. За улеснение на диагностика в заглавието на процеса sshd, видимо при използване на утилитата ps, е осигурено показването на броя на текущо аутентифицираните връзки и състоянието на лимита MaxStartups;
• В ssh и ssh-agent при извикване на програмата за показване на поканата, зададена чрез $SSH_ASKPASS, сега допълнително се предава флаг с типа на поканата: «confirm» — диалог за потвърждение (да/не), «none» — информационно съобщение, «blank» — запитване за парола;
• В ssh-keygen е добавена нова операция с цифрови подписи «find-principals» за търсене в файла allowed-signers на потребителя, свързан с указаната цифрова подпис;
• Подобрена е поддръжката на изолацията на процеса sshd в Linux чрез механизма seccomp: системните повиквания IPC са забранени, clock_gettime64(), clock_nanosleep_time64 и clock_nanosleep() са разрешени.

Източник: opennet.ru