The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз OpenSSH 8.5

03.03.2021 08:10

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


  1. Главная ссылка к новости (https://lists.mindrot.org/pipe...)
  2. OpenNews: Релиз OpenSSH 8.4
  3. OpenNews: Уязвимость в SSH-клиентах OpenSSH и PuTTY
  4. OpenNews: Релиз OpenSSH 8.3 с устранением уязвимости в scp
  5. OpenNews: Релиз OpenSSH 8.2 c поддержкой токенов двухфакторной аутентификации FIDO/U2F
  6. OpenNews: Уязвимости в реализациях SCP из OpenSSH, PuTTY и WinSCP
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/54690-openssh
Ключевые слова: openssh
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (42) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:34, 03/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –21 +/
    Что-то сегодня всё больше dropbear вижу, про сабж никто и не думает.
     
     
  • 2.2, Аноним (1), 09:36, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А ну ещё teleport может быть, раньше то один dropbear был повсеместно.
     
  • 2.4, Аноним (4), 09:42, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +8 +/
    А в чём прикол? Какая-то шарага заморочилась протолкнуть его штатно на хостинге? Никогда не видел его в живую на нормальных хостингах.
     
     
  • 3.6, Аноним (1), 09:58, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Я не знаю, не я выбирал. Может быть, совместимость с легаси триггерит девопсов.
     
  • 2.16, YetAnotherOnanym (ok), 11:19, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Сравнил пинцет для бровей с мультитулом.
     
     
  • 3.17, Аноним (1), 11:24, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    А какие применения вы видите? Более близкое сравнение будет ЭВМ 50х годов и сегодняшние телефоны.
     
     
  • 4.23, Аноним (23), 13:39, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ЭВМ 50-х годов остались в 50-х. А сабж прекрасно развивается и сейчас, чему свидетельством — данная новость.
     
     
  • 5.25, Аноним (1), 13:55, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > ЭВМ 50-х годов остались в 50-х. А сабж прекрасно развивается и сейчас,
    > чему свидетельством — данная новость.

    Ну почему, вон мейнфреймы тех лет как и кобол до сих пор используются.

     
  • 2.34, Owlet (?), 19:47, 04/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Никогда не видел этого dropbear в реальной жизни, только sshd.
     
     
  • 3.37, Аноним (37), 23:48, 04/03/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    На роутерах стоит dropbear, ибо всего в обрез.
     

  • 1.3, Аноним (4), 09:41, 03/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    >> UpdateHostKeys

    А вот есть что-то такое же, но для обновления на сервере ключей клиента в чуть более штатном и автоматическом режиме, чем костылями? Проблеме как бы дофига лет, а до сих пор вместо решения извращения всякие

     
     
  • 2.5, Аноним (5), 09:47, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Решение есть. В следующий раз когда будет сообщение с кучей букв и словами warning key mismatch просто нажать Yes, Remember key
     
     
  • 3.20, Аноним (4), 12:34, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    и при чём тут ключи клиентов? С не тем ключом ты тупо не авторизуешься, без всяких ворнингов. А с тем ты не обеспечишь автоматическую замену устаревшего ключа.
     
  • 2.14, Просто (?), 10:44, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ansible, Puppet?
     
     
  • 3.21, Аноним (4), 12:36, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это не штатный инструмент OpenSSH, а нагромождение костылей, которые либо имеют не нулевой шанс угробить старый конфиг развалив авторизацию, либо пытаются заменить собой единую точку авторизации в корпоративном сегменте, хотя это то как раз и ошибочный путь.
    А когда есть пачка разных серверов, от разных кастомеров и нужно по ним ходить ручками, нужен именно штатный механизм обновления ключей, не предполагающий установку доп. ПО всем подряд
     
     
  • 4.29, Просто (?), 16:56, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Весь мир использует эти и аналогичные средства автоматизации. А тебе штатные механизмы конкретного софта подавай..
    Ну так реализуй, сделай коммит :D С дивана вещать-то легко.

    > не предполагающий установку доп. ПО всем подряд

    С каких пор Ansible требует установки ПО на сервера?

     
     
  • 5.41, PereresusNeVlezaetBuggy (ok), 16:33, 05/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Python он требует. Так что изредка сталкиваюсь с тем, что надо сначала его накатить прежде чем включать сервер в ansible/hosts.
     
     
  • 6.42, Анончик (?), 15:11, 06/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не нужно это тут рассказывать. Они начнут кричать что только некоторые модули треуют питона на сервере и ты можешь переписать их на баш. А потом продолжат уверять что у них agentless
     
     
  • 7.43, gred (ok), 21:55, 06/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    есть еще cdist, но да, слегка маргинален, возможно.
     
  • 2.26, Аноним (26), 14:20, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    ssh сертификаты умеет, меняйте хоть каждый день.
     
  • 2.44, FSA (??), 10:08, 11/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Генерируешь новый ключ на своей машине. Дальше с помощью ssh-copy-id копируете на нужные хосты, где есть старые ключи. Старые ключи удаляете.
     

  • 1.8, Аноним (8), 10:10, 03/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Если я верно помню, в протоколах, где хеш используется для подписи самого сертификата (но не других данных), коллизионная стойкость хеша не имеет значения (потому что требует соучастия стороны, генерирующей ключ, а в таких случаях сторона, генеиирующая ключ может просто выдать приватный ключ вместо генерации коллизии), они полагаются на second preimage resistance, а это разные вещи.
     
     
  • 2.9, Аноним (8), 10:10, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вернее не ключ, а сертификат.
     

  • 1.10, Аноним (8), 10:13, 03/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Среди рекомендуемых для миграции алгоритмов упомянуты 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).

    А в dropbear они из коробки поддерживаются (ed25519 точно нет, в роутерах что флехи, что памяти мало, поэтому режут всё, что только могут, даже по живому)? А если нет, то и сюда нет.

     
     
  • 2.15, Аноним (15), 10:45, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > А в dropbear они из коробки поддерживаются

    ed25519 _из_коробки_ - точно поддерживается. А если в твоем роутере нарочно его удалили -  increases binary size - around 7,5kB on x86-64 - то выброси это недоразумение.

     
     
  • 3.31, Аноним (37), 22:10, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    https://openwrt.org/docs/guide-user/security/dropbear.public-key.auth#providin

    >Rebuild Dropbear with Ed25519 key type support.
    >cat << EOF >> openwrt/.config
    >CONFIG_DROPBEAR_ED25519=y
    >EOF

    Why the f*** should I run the untrusted toolchain on my machine?

     
     
  • 4.32, . (?), 13:05, 04/03/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Спроси у своего trusted shitwrt или как там его, зачем они сэкономили аж 7.5k
    В _дефолтном_ конфиге в исходниках dropbear включено по умолчанию, надо было не полениться специально это испортить.
     
     
  • 5.36, Аноним (37), 23:47, 04/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что там реально памяти в обрез. Что на 4 MB флехи, что на 8 и 32 оперативы. Всё падает на хрен при минимальном добавлении необходимых сервисов даже на 8/32, на 4 на флеху вообще только бы базовый образ влез, ни о каком веб-интерфейсе и Luci и речи не идёт, чувствую, что покупать и перепаивать придётся что флеху, что оперативу, благо что доступ к SMD-станции и сухому азоту есть.
     
  • 2.33, edo (ok), 17:59, 04/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > А в dropbear они из коробки поддерживаются (ed25519 точно нет, в роутерах что флехи, что памяти мало, поэтому режут всё, что только могут, даже по живому)

    В пределах оно не поддерживается просто потому, что поддержка ed25519 не так давно в dropbear появилась, не все успели обновиться

     

  • 1.12, Аноним (8), 10:17, 03/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >В ssh для ключей FIDO обеспечен повторный запрос PIN в случае сбоя операции с цифровой подписью из-за некорректного PIN и отсутствия запроса PIN у пользователя (например, когда не удалось получить корректные биометрические данные и устройство откатилось на ручной ввод PIN-а).

    Вы ещё аттестацию прикрутите.

     
  • 1.13, Аноним (15), 10:25, 03/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    > стоимость подбора коллизии оценивается примерно в 50 тысяч долларов

    долбанные белки-истерички. Дайте мне 40, я вам отдам все свои ключи и так, без ненужной возни (и хер вы потом меня найдете).

     
     
  • 2.18, Ананимус (?), 11:25, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Это всего 2.6 миллиона рублей.
     
     
  • 3.19, пох. (?), 12:02, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я готов и рублями, тащите уже ж!

     
  • 2.22, Сейд (ok), 12:41, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Продам новые ключи SSH за 1 биткойн, 5 штук.
     
     
  • 3.24, пох. (?), 13:46, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    херассе ты жадный!

    Да ладно, чего там - продам и новые за те же $50000, чур - налом, купюрами не крупнее двадцатки.

     
     
  • 4.30, Сейд (ok), 21:04, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Обсудим организацию картеля в XMPP?
     
  • 4.35, Аноним (-), 23:47, 04/03/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это все нивалидная фигня. Я буду валидировать ключи за 60% стоимости.
     

  • 1.27, Аноним (27), 14:23, 03/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    После обновления клиента на 8.4 не получилось полключиться к роутеру по ключу. Хорошо, что оставили возможность подключения с настройкой PubkeyAcceptedKeyTypes ssh-rsa.
     
     
  • 2.28, Аноним (1), 14:26, 03/03/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > После обновления клиента на 8.4 не получилось полключиться к роутеру по ключу.
    > Хорошо, что оставили возможность подключения с настройкой PubkeyAcceptedKeyTypes ssh-rsa.

    Серьёзно? Чёрт, а я переживал, что это с моим роутером. Ололошечки.

     

  • 1.38, Бернулли (?), 23:52, 04/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Здравствуйте!
    Подскажите, sntrup761x25519-sha512@openssh.com а это как?

    Х25519 это Диффи-Хельман с кривой 25519, sntrup761 это NTRUEncrypt - шифрование с публичным ключем.
    Получается ntru шифрует открытый ключ кривой 25519?

     
     
  • 2.39, Бернулли (?), 01:44, 05/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Дошло:
    * c,r_enc = Hide(r,pk,cache); cache is Hash4(pk) */

    r 256 бит вполне хватает что бы публичный ключ передать от кривой


    Или не прав?)

     
     
  • 3.40, Бернулли (?), 02:29, 05/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    https://github.com/openssh/openssh-portable/blob/master/kexsntrup761x25519.c
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру