След четири месеца разработка освобождаване , отворена клиентска и сървърна реализация за работа чрез протоколите 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 (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).
Други промени:
- Директивата Include е добавена към sshd_config, което позволява съдържанието на други файлове да бъде включено в текущата позиция на конфигурационния файл (глобалните маски могат да се използват при указване на името на файла);
- Към ssh-keygen е добавена опцията „no-touch-required“, която деактивира необходимостта от физическо потвърждение за достъп до токена при генериране на ключ;
- Директивата PubkeyAuthOptions е добавена към sshd_config, консолидирайки различни опции, свързани с удостоверяване с публичен ключ. В момента се поддържа само флагът „no-touch-required“, което позволява пропускане на проверката за физическо присъствие по време на удостоверяване с токен. По подобен начин, опцията „no-touch-required“ е добавена към файла authorized_keys.
- Опцията „-O write-attestation=/path“ е добавена към ssh-keygen, което позволява записването на допълнителни FIDO сертификати за атестация при генериране на ключове. OpenSSH в момента не използва тези сертификати, но те могат да бъдат използвани в бъдеще, за да се провери дали ключът се съхранява в надеждно хардуерно хранилище.
- В настройките на ssh и sshd вече е възможно да се зададе режимът на приоритизиране на трафика чрез директивата IPQoS. (Поведение с по-ниско усилие на скок);
- В ssh, при задаване на стойност "AddKeysToAgent=yes", ако ключът не съдържа поле за коментар, той ще бъде добавен към ssh-agent с пътя до ключа, посочен като коментар.
ssh-keygen и ssh-agent вече използват PKCS#11 етикети и името на темата X.509 като коментари в ключа, вместо пътя до библиотеката; - Добавена е възможността за експортиране на PEM за DSA и ECDSA ключове към ssh-keygen;
- Добавен е нов изпълним файл ssh-sk-helper, използван за изолиране на достъпа на библиотеката до FIDO/U2F токени;
- Добавена е опция за компилиране "--with-zlib" към ssh и sshd за компилиране с поддръжка на zlib библиотека;
- В съответствие с RFC 4253, в банера на връзката вече се показва предупреждение за блокиран достъп поради превишаване на лимита 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
