Після п'яти місяців розробки представлений реліз 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; ключ повинен бути присутнім лише під одним ім'ям; не повинен застосовуватись сертифікат хостового ключа; у known_hosts не повинно застосовуватись масок на ім'я хоста; має бути вимкнено налаштування VerifyHostKeyDNS; має бути активований параметр UserKnownHostsFile.
Серед рекомендованих для міграції алгоритмів згадані rsa-sha2-256/512 на базі RFC8332 RSA SHA-2 (підтримується з OpenSSH 7.2 та використовується за замовчуванням), ssh-ed25519 (підтримується з OpenSSH 6.5) та ecdsa2/256 з урахуванням RFC384 ECDSA (підтримується з OpenSSH 521).
Інші зміни:
- Зміни, пов'язані з безпекою:
- У 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. Вместо [захищено електронною поштою] метод теперь идентифицируется как [захищено електронною поштою] (Алгоритм sntrup4591761 замінений на sntrup761).
- У ssh і sshd змінено порядок анонсування алгоритмів цифрових підписів, що підтримуються. Першим тепер пропонується ED25519 замість ECDSA.
- У ssh і sshd встановлення параметрів якості обслуговування TOS/DSCP для інтерактивних сеансів тепер здійснюється до встановлення TCP-з'єднання.
- У ssh та sshd припинено підтримку шифру [захищено електронною поштою]який ідентичний 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