После пяти месяцев разработки представлен релиз 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.
Вы должны войти