След пет месеца разработка е представена версията на OpenSSH 8.5, отворена реализация на клиент и сървър за работа по протоколите SSH 2.0 и SFTP.
Разработчиците на OpenSSH ни напомниха за предстоящото извеждане от експлоатация на алгоритми, използващи SHA-1 хешове поради повишената ефективност на атаките на сблъсък с даден префикс (цената за избор на сблъсък се оценява на приблизително 50 хиляди долара). В една от предстоящите версии те планират да деактивират по подразбиране възможността за използване на алгоритъма за цифров подпис с публичен ключ „ssh-rsa“, който е споменат в оригиналния RFC за SSH протокола и остава широко разпространен в практиката.
За да тествате използването на ssh-rsa на вашите системи, можете да опитате да се свържете чрез ssh с опцията „-oHostKeyAlgorithms=-ssh-rsa“. В същото време деактивирането на цифровите подписи „ssh-rsa“ по подразбиране не означава пълно изоставяне на използването на RSA ключове, тъй като в допълнение към SHA-1 протоколът SSH позволява използването на други алгоритми за изчисляване на хеш. По-специално, в допълнение към „ssh-rsa“, ще остане възможно използването на пакетите „rsa-sha2-256“ (RSA/SHA256) и „rsa-sha2-512“ (RSA/SHA512).
За плавен преход към нови алгоритми, OpenSSH 8.5 има настройката UpdateHostKeys, активирана по подразбиране, което позволява на клиентите автоматично да превключват към по-надеждни алгоритми. С помощта на тази настройка се активира специално разширение на протокола "[имейл защитен]“, което позволява на сървъра, след удостоверяване, да информира клиента за всички налични хост ключове. Клиентът може да отрази тези ключове в своя ~/.ssh/known_hosts файл, който позволява ключовете на хоста да бъдат актуализирани и улеснява промяната на ключовете на сървъра.
Използването на UpdateHostKeys е ограничено от няколко предупреждения, които може да бъдат премахнати в бъдеще: ключът трябва да бъде споменат в UserKnownHostsFile и да не се използва в GlobalKnownHostsFile; ключът трябва да присъства само под едно име; не трябва да се използва сертификат за ключ на хост; в unknown_hosts не трябва да се използват маски по име на хост; настройката VerifyHostKeyDNS трябва да бъде деактивирана; Параметърът UserKnownHostsFile трябва да е активен.
Препоръчителните алгоритми за миграция включват 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).
Други промени:
- Промени в сигурността:
- Уязвимост, причинена от повторно освобождаване на вече освободена област от паметта (double-free), е коригирана в ssh-agent. Проблемът съществува от пускането на OpenSSH 8.2 и потенциално може да бъде използван, ако нападател има достъп до гнездото на ssh-agent в локалната система. Това, което прави експлоатацията по-трудна е, че само root и оригиналният потребител имат достъп до сокета. Най-вероятният сценарий на атака е агентът да бъде пренасочен към акаунт, който се контролира от атакуващия, или към хост, където атакуващият има root достъп.
- sshd добави защита срещу предаване на много големи параметри с потребителското име към подсистемата PAM, което ви позволява да блокирате уязвимости в модулите на системата PAM (Pluggable Authentication Module). Например, промяната предотвратява използването на sshd като вектор за използване на наскоро открита основна уязвимост в Solaris (CVE-2020-14871).
- Потенциално нарушаващи съвместимостта промени:
- В ssh и sshd е преработен експериментален метод за обмен на ключове, който е устойчив на отгатване на квантов компютър. Квантовите компютри са радикално по-бързи при решаването на проблема с разлагането на естествено число на прости множители, което е в основата на съвременните асиметрични алгоритми за криптиране и не може да бъде ефективно решено на класически процесори. Използваният метод се основава на алгоритъма NTRU Prime, разработен за пост-квантови криптосистеми, и метода за обмен на ключове с елиптична крива X25519. Вместо [имейл защитен] методът вече е идентифициран като [имейл защитен] (алгоритъмът sntrup4591761 е заменен от sntrup761).
- В ssh и sshd редът, в който се съобщават поддържаните алгоритми за цифров подпис, е променен. Сега първо се предлага ED25519 вместо ECDSA.
- В ssh и sshd настройването на TOS/DSCP параметри за качество на услугата за интерактивни сесии вече се извършва преди установяване на TCP връзка.
- Поддръжката на Cipher е преустановена в ssh и sshd [имейл защитен], който е идентичен на aes256-cbc и е използван преди одобрението на RFC-4253.
- По подразбиране параметърът CheckHostIP е деактивиран, чиято полза е незначителна, но използването му значително усложнява ротацията на ключове за хостовете зад балансиращите на натоварването.
- Настройките PerSourceMaxStartups и PerSourceNetBlockSize са добавени към sshd, за да се ограничи интензивността на стартиращите манипулатори въз основа на адреса на клиента. Тези параметри ви позволяват да контролирате по-фино ограничението за стартиране на процеси в сравнение с общата настройка MaxStartups.
- Добавена е нова настройка LogVerbose към ssh и sshd, която ви позволява принудително да повишите нивото на информацията за отстраняване на грешки, изхвърлена в дневника, с възможност за филтриране по шаблони, функции и файлове.
- В ssh, когато се приема нов хост ключ, се показват всички имена на хостове и IP адреси, свързани с ключа.
- ssh позволява опцията UserKnownHostsFile=none да деактивира използването на файла known_hosts при идентифициране на ключове на хост.
- Добавена е настройка на KnownHostsCommand към ssh_config за ssh, което ви позволява да получавате данни на unknown_hosts от изхода на посочената команда.
- Добавена е опция PermitRemoteOpen към ssh_config за ssh, за да ви позволи да ограничите дестинацията, когато използвате опцията RemoteForward със SOCKS.
- В ssh за ключове FIDO се предоставя повторна заявка за ПИН в случай на неуспешна операция за цифров подпис поради неправилен ПИН и потребителят не получава подкана за ПИН (например, когато не могат да бъдат получени правилните биометрични данни и устройството се върна към ръчно въвеждане на PIN).
- sshd добавя поддръжка за допълнителни системни извиквания към базирания на seccomp-bpf механизъм за изолиране на процеси в Linux.
- Помощната програма contrib/ssh-copy-id е актуализирана.
Източник: opennet.ru