Релиз OpenSSH 8.5
3 марта 2021 года
После пяти месяцев разработки представлен релиз 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.
Источники[править]
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии[править]
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.