Logo Host-telecom.com — профессиональный хостинг в Европе! Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
ATLEX Выделенные серверы: в Европе / в России.

Виртуальные серверы: в Европе / в России.

Партнерская программа

Ваш сайт в 8 раз быстрее конкурентов. Хостинг от $2.95

VPS: SSD, KVM, бесплатные бэкапы и администрирование

Все необходимое для вашего сайта и лучшая техподдержка 24/7

хостинг сайтов ГиперХост — хостинг сайтов который Вы искали.

Виртуальный хостинг, Аренда VPS серверов, рация доменных имен, SSL сертификаты

💰 Самые низкие цены на домены

🔒 Отличный хостинг на SSD c бесплатными SSL

💻 Огромнейший выбор dedicated выделенных серверов

Представлен релиз OpenSSH 8.5

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

Ваш комментарий

Имя:

Текст комментария (HTML-теги не допускаются):

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

Мощные сервера

VPS с гибкой конфигурацией: за 1€

Мощные выделенные сервера: от 25€

Собственный Дата-Центр
Поддержка 24/7

хостинг Украина Виртуальный хостинг для сайта от $4,87

Регистрация домена от $2 в год

Партнерская программа – $20 за клиента

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

Новости мира IT:

Архив новостей

Последние комментарии:

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...