След пет месеца разработка е представена версия 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, която позволява автоматично преминаване на клиентите към по-надеждни алгоритми. С помощта на тази настройка се активира специално разширение на протокола „hostkeys@openssh.com“, което позволява на сървъра след преминаване на аутентификацията да информира клиента за всички налични ключове на хоста. Клиентът може да запише тези ключове в своя файл ~/ .ssh/known_hosts, което позволява организиране на обновяване на ключовете на хоста и опростява смяната на ключове на. сървър.
Използването на UpdateHostKeys е ограничено с няколко условия, които в бъдеще могат да бъдат отменени: ключът трябва да бъде споменат в UserKnownHostsFile и не трябва да се използва в GlobalKnownHostsFile; ключът трябва да присъства само под едно име; не трябва да се използва сертификат на хостовия ключ; в known_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).
Други промени:
- Промени, свързани с безопасността:
- В ssh-agent е отстранена уязвимост, причинена от повторно освобождаване на вече освободена памет (double-free). Проблемът се проявява от версия OpenSSH 8.2 и потенциално може да бъде експлоатиран при наличие на достъп на атакуващия до сокета на ssh-agent на локалната система. Усложнението за експлоатация е, че достъп до сокета имат само root и оригиналният потребител. Най-вероятният сценарий за атака е пренасочване на агента към акаунт, който е под контрол на злонамерен потребител, или към хост, на който злонамереният потребител има root-достъп.
- В sshd е добавена защита от предаване на много големи параметри с име на потребител към подсистемата PAM, което позволява блокиране на уязвимости в системните модули PAM (Pluggable Authentication Module). Например, промяната позволява да се предотврати използването на sshd като вектор за експлоатация на наскоро откритата root-уязвимост в Solaris (CVE-2020-14871).
- Промени, които потенциално нарушават съвместимостта:
- В ssh и sshd е преработен експериментален метод за обмяна на ключове, устойчив на атаки от квантови компютри. Квантовите компютри решават значително по-бързо задачата за разлагане на натурални числа на прости множители, което е основата на съвременните асиметрични алгоритми за шифроване и е ефективно неразрешимо на класически процесори. Използваният метод е базиран на алгоритъма NTRU Prime, разработен за постквантови криптосистеми, и метод за обмен на ключове на база елиптични криви X25519. Вместо sntrup4591761x25519-sha512@tinyssh.org, методът сега се идентифицира като sntrup761x25519-sha512@openssh.com (алгоритъмът sntrup4591761 е заменен с sntrup761).
- В ssh и sshd е променен редът на обявяване на поддържаните алгоритми за цифрови подписи. Сега първо се предлага ED25519 вместо ECDSA.
- В ssh и sshd настройката на параметрите за качество на услугата TOS/DSCP за интерактивни сесии сега се извършва преди установяване на TCP връзката.
- В ssh и sshd е прекратена поддръжката на шифъра rijndael-cbc@lysator.liu.se, който е идентичен на aes256-cbc и е използван до утвърдването на RFC-4253.
- По подразбиране е деактивиран параметърът CheckHostIP, чиято полза е незначителна, но употребата му усложнява значително ротацията на ключовете за хостове зад балансировчици на натоварването.
- В sshd са добавени настройки PerSourceMaxStartups и PerSourceNetBlockSize за ограничаване на интензитета на стартиране на обработчици, свързани с адреса на клиента. Указаните параметри позволяват по-фино управление на ограниченията за стартиране на процеси в сравнение с общата настройка MaxStartups.
- В ssh и sshd е добавена нова настройка LogVerbose, която позволява принудително повишаване на нивото на записваната в лог отладъчна информация с възможност за филтриране по шаблони, функции и файлове.
- В ssh, при приемане на нов хостов ключ, се осигурява показването на всички имена на хостове и IP адреса, асоциирани с ключа.
- В ssh е разрешено указването на опцията UserKnownHostsFile=none за деактивиране на използването на файла known_hosts при идентификация на хостовите ключове.
- В ssh_config за ssh е добавена настройка KnownHostsCommand, която позволява получаване на данни от known_hosts от изхода на посочената команда.
- В ssh_config за ssh е добавена опция PermitRemoteOpen, която позволява ограничаване на дестинацията при използването на опцията RemoteForward с SOCKS.
- В ssh за ключовете FIDO е предвиден повторен вход на PIN при неуспех на операцията с цифров подпис поради неправилен PIN и липсата на искане за PIN от потребителя (например, когато не успее да получи правилни биометрични данни и устройството се върне към ръчно въвеждане на PIN).
- В sshd е добавена поддръжка на допълнителни системни повиквания към механизма за изолация на процесите, основан на seccomp-bpf, на платформата Linux.
- Актуализиран е инструментът contrib/ssh-copy-id.
Източник: opennet.ru
