След четири месеца разработка освобождаване , отворена клиентска и сървърна реализация за работа чрез протоколите 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). Междинна библиотека libsk-libfido2, подготвена от разработчиците на OpenSSH в ядрото libfido2, както и за OpenBSD.
За да удостоверите и генерирате ключ, трябва да посочите параметъра „SecurityKeyProvider“ в настройките или да зададете променливата на средата SSH_SK_PROVIDER, указваща пътя към външната библиотека libsk-libfido2.so (експорт SSH_SK_PROVIDER=/path/to/libsk-libfido2. така). Възможно е да се изгради 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, която ви позволява да включите съдържанието на други файлове в текущата позиция на конфигурационния файл (глобалните маски могат да се използват, когато посочвате името на файла);
- Опцията „не се изисква докосване“ е добавена към ssh-keygen, която деактивира необходимостта от физическо потвърждаване на достъпа до токена при генериране на ключа;
- Към sshd_config е добавена директива PubkeyAuthOptions, която комбинира различни опции, свързани с удостоверяване с публичен ключ. Понастоящем се поддържа само флагът „не се изисква докосване“ за пропускане на проверките за физическо присъствие за удостоверяване на токена. По аналогия към файла authorized_keys е добавена опцията „no-touch-required“;
- Добавена е опция „-O write-attestation=/path“ към ssh-keygen, за да се позволи записването на допълнителни сертификати за удостоверяване на FIDO при генериране на ключове. OpenSSH все още не използва тези сертификати, но те могат да бъдат използвани по-късно, за да се провери дали ключът е поставен в доверен магазин за хардуер;
- В настройките на ssh и sshd вече е възможно да се зададе режим на приоритизиране на трафика чрез директивата IPQoS (поведение при по-ниско усилие на скок);
- В ssh, когато зададете стойността „AddKeysToAgent=yes“, ако ключът не съдържа поле за коментар, той ще бъде добавен към ssh-agent, посочвайки пътя до ключа като коментар. IN
ssh-keygen и ssh-agent също сега използват PKCS#11 етикети и името на субекта X.509 вместо пътя на библиотеката като коментари в ключа; - Добавена е възможност за експорт на PEM за DSA и ECDSA ключове към ssh-keygen;
- Добавен е нов изпълним файл, ssh-sk-helper, използван за изолиране на библиотеката за достъп до токени FIDO/U2F;
- Добавена е опция за изграждане „--with-zlib“ към ssh и sshd за компилиране с поддръжка на zlib библиотека;
- В съответствие с изискването на RFC4253, предупреждение за блокиране на достъпа поради превишаване на лимитите MaxStartups се предоставя в банера, показван по време на връзката. За да се опрости диагностиката, заглавката на sshd процеса, видима при използване на помощната програма ps, сега показва броя на текущо удостоверените връзки и състоянието на ограничението MaxStartups;
- В ssh и ssh-agent, при извикване на програма за показване на покана на екрана, зададена чрез $SSH_ASKPASS, сега допълнително се предава флаг с типа на поканата: “confirm” - диалогов прозорец за потвърждение (да/не), “няма ” - информационно съобщение, „празно” — искане за парола;
- Добавена е нова операция за цифрови подписи „find-principals“ към ssh-keygen за търсене във файла с разрешени подписи за потребителя, свързан с определен цифров подпис;
- Подобрена поддръжка за изолиране на sshd процеси в Linux с помощта на механизма seccomp: деактивиране на IPC системни повиквания, разрешаване на clock_gettime64(), clock_nanosleep_time64 и clock_nanosleep().
Източник: opennet.ru