След четири месеца разработка релиз , открито реализиране на клиент и сървър за работа с протоколите SSH 2.0 и SFTP.
Основното подобрение в изданието OpenSSH 8.2 е възможността за използване на двуфакторна автентификация чрез устройства, поддържащи протокола , развиван от алианса . U2F позволява създаването на евтини хардуерни токени за потвърждаване на физическото присъствие на потребителя, взаимодействието с които се извършва чрез USB, Bluetooth или NFC. Подобни устройства се предлагат като средство за двуфакторна автентикация на сайтове, вече се поддържат от основните браузъри и се произвеждат от различни производители, включително Yubico, Feitian, Thetis и Kensington.
За взаимодействие с устройства, удостоверяващи присъствието на потребителя, в OpenSSH са добавени нови типове ключове "ecdsa-sk" и "ed25519-sk", които използват ECDSA и Ed25519 цифрови подписи, комбинирани с хеш алгоритъма SHA-256. Процедурите за взаимодействие с токените са изнесени в междинна библиотека, която се зарежда по аналогия с библиотеката за поддръжка на PKCS#11 и служи като обвивка над библиотеката. , предоставяща средства за комуникация с токените върху USB (поддържат се протоколи FIDO U2F/CTAP 1 и FIDO 2.0/CTAP 2). Подготвената от разработчиците на OpenSSH междинна библиотека libsk-libfido2 е част от libfido2, подобно на за 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 вече е възможно да се зададе режим на приоритизиране на трафика (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
