Разработчики проекта OpenSSH представили план прекращения поддержки ключей на базе алгоритма DSA. По современным меркам DSA-ключи не обеспечивают должного уровня защиты, так как используют размер закрытого ключа всего в 160 бит и хэш SHA1, что по уровню безопасности соответствует примерно 80 разрядному симметричному ключу...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60426
Астрологи объявили проблемы с доступом к древнему железу на лето
Древнее железо самостоятельно накатит на себя свежий OpenSSH?
клиент сломается
У любителей "с-лопаты-посвежее"? Ну будет на арче +1 поломка - одной больше, одной меньше - ЦА и не заметит, им не привыкать.
Закоренелый, успокойся, тебе никто не мешает держать древнее.
> Закоренелый, успокойся, тебе никто не мешает держать древнее.Так не я ж кипишую с "Ааааа! все пропало! Самоновейшую железку 2010 года с арча 2025 админить низзя!!!11расрасрас"
Как сломается? Столлман ночью обновление накатит и старый код отберёт? Или в твоей слаке до сих пор не осилили разные версии софта на одной системе держать?
астрологи как обычно висят в облаках :)
а практики используют то что нужно там где нужно :)
древнее железо даже с телнетом можно элементарно закрыть от тырнетика... но астрологи приземленное не видят :)
Разумеется можно, только это никак не отменит того факта что в системе алгоритма нет, а на железке есть, и если железку обновить нельзя, то "придется" сидеть на древней оси чтобы иметь возможность поправить настройки железки, или элементарно перезагрузить..Тут недавно принесли старый коммутатор управляемый, у которого нет ничего кроме http, задача сбросить настройки и использовать как обычный хаб, вот только там http 0.9 , пришлось доствать какуюто древнюю копию какой-то XP и через интернет эксплорер...
Шо значит алгоритма нет? Этих ssh клиентов как грязи, если уж нужно зайти на древнюю железяку, то можно взять тот же putty или ещё опакетить старую ssh. В общем это не проблема в ближайщие 10-15 лет.
никто и не говорит, что это фатальная и непреодолимая проблема, но определенное неудобство, хочешь ты на железку, а тебе хрен, вот качай чего-то там, законопачивай в пакет...почему бы например не вынести старые алгоритмы в пакет ssh-legacy и ставить его при необходимости, разумеется можно, но майнтейнеры этим заниматься не будут, разрабы ssh тоже сливаются, дебиановци нашли выход с openssh-client-ssh1, но видимо это будет ssh-v1, или чтото такое, а можно было бы решить на уровне самого ssh, чтобы оно выдавало сообщение, типа хост к которому вы подключаетесь старый хлам, если хотите продолжить доустановите пакет/библиотеку ssh-legacy. Разве это не было бы лучше ?
Этих неудобств со старым оборудованием уже дофига, +/- еще одно погоды не сделает.
Но раньше как-то больше UI и браузеров касалось: SSL, IE, Java 6, Flash.
В общем прогресс не стоит на месте.
Но думаю, что самой проблемой будет работа с такими устройствами автоматическими системами, которые по SSH к ним подключаются.
С какого-то момента придется telnet включать, если есть.
Ну так а чеж ты только тут коментики такие строчишь, а не пошел в мантейнеры openssh чтобы оставить и подерживать этот ssh-legacy? А в прочем и так знаю.
потому что за всеми любителями разрушать до основания и построить какое-то г-но - не находишься.
Человеческая цивилизация держалась (уже - постфактум) на сотрудничестве а не явном вредительстве.
И http 0.9 прекрасно работает в 2.0.17 firefox. Берёшь portable версию под нужную ось и настраиваешь. Опять же не проблема при наличии мозга и рук.
а оригинальный ms-dos запускается на 486 пне спаять который тоже не проблема при наличии....Вот скажи человече, надо оно мне? фаерфокс 2.0.17 в 2023 тода еще году, если у вас там некромантии храм и вы поклоняетесь мертвым то ради бога, ваши проблемы.
Ты по-моему уже запутался чего тебе нужно. Если нужно настроить древнюю железяку, то поставить древний фф намного быстрее, чем брать древнюю хп с древним ие.
Так ведь никто не мешает использовать для таких дел легковесный контейнер с любой понравившейся обвязкой для или nix-shell. Кажется, что «держать на локалхосте разные версии утилиты» в 2024 году не является проблемой.
Еще вариант просто поставить прокси где-то.P.S. (про руки и ум не пишу, потому что эта фраза скорее характеризует пишущего, чем тому, кому написано)
Есть мнение, что на сегодняшний день DSA-ключами действительно пользуются только сумасшедшие астрологи.
Предполагаю, что там где оно есть - это что-то из разряда "как прибили - так и держится"
Как прибили, так пол ляма зелени жалко на замену.
> Как прибили, так пол ляма зелени жалко на замену.Думаю, нет - так, чтобы железка умела _только_ в DSA-ключи я не помню. Т.е. не то, чтобы я железячник, хорошо знающий эмбеддовку - но вот не видел и пожалуй даже не слышал. А сгенерированные DSA-ключи видел, в том числе и в своем исполнении - правда давнёооохонько то дело было...
>> Как прибили, так пол ляма зелени жалко на замену.
> Думаю, нет - так, чтобы железка умела _только_ в DSA-ключи я не
> помню. Т.е. не то, чтобы я железячник, хорошо знающий эмбеддовку -
> но вот не видел и пожалуй даже не слышал. А сгенерированные
> DSA-ключи видел, в том числе и в своем исполнении - правда
> давнёооохонько то дело было...Привет железкам из 95го от производителей, сотрудничавших с НИСТ (там DSA был верхом совершенства, остальное абсолютный попил)
> затраты на продолжение сопровождения небезопасного алгоритма DSAврунишки. Затраты на сопровождение еще одного варианта параметра для вызова openssl равны нулю.
> Пользователи, которым необходима поддержка DSA на стороне
> клиента, смогут использовать альтернативные сборки прошлых
> веток OpenSSHсо всеми багами и уязвимостями (никак не привязанными к DSA) которые никто не собирается исправлять а половина из них и неизвестна никому кроме _уважаемых_.
Вот это-то точно надежно и безопастно, не то что просто не трогать работающий код.
make OPENSSL=no году в 2015 появилась, так-то.
Ничего что при такой сборке не то что dsa, а вообще ни один алгоритм кроме карманных djbшных не поддерживается в принципе? Секьюрить!
> Ничего что при такой сборке не то что dsa, а вообще ни
> один алгоритм кроме карманных djbшных не поддерживается в принципе? Секьюрить!Не то, чтобы в этом было что-то плохое... Хотя нет, протокол, завязанный на один единственный алгоритм (Кто сказал "вайргард"?!) - не есть гут, но openssl'ные "миллион возможностей выстрелить себе в ногу" тоже не оч-то.
> но openssl'ные "миллион возможностей выстрелить себе в ногу" тоже не оч-то.к сожалению, "разработчики" openssh всегда были сильны в FUD а не в крипто.
Все на что их хватило в далеком 2003м - это выпилить-выпилить непонятные и сложные им криптореализации Йлонена и запилить интерфейсик к openssl (причем - к тогдашней, ужос-ужос).
Ну вот теперь у них есть еще один, упрощенный, к nacl (творчески переосмысленной но это все еще она) - снова не они писали, там сплошная копипаста.В результате нет ни совместимости с другими реализациями, ни гарантий что там не всплывет какой-нибудь способ свести всю секьюрити к xor'ам.
Уж лучше оставить openssl - теперь это единственный доступный выбор.
(ну и в принципе - авторизация по сертификатам в конечном итоге все же лучше чем предлагаемые альтернативы, а она уж точно без openssl нереальна)
надежнтопешытя правельна
Пример этих утверждений в студию, пожалуйста. И не чтобы "при полной луне, когда юзер поставил 100 параметров в определенные значения и выпил чаю, то...)
>затраты на продолжение сопровождения небезопасного алгоритма DSA не оправдывают себяИнтересно.. в чем затраты на продолжение сопровождения? Платят, что бы ничего не трогали?
Затраты на удаление - я понимаю...
Представь, что тебе не очень часто, но регулярно пишут пользователи.
С какими-то проблемами с куском кода который супер старый и супер мутный.
И тебе приходится им что-то отвечать, может даже что-то смотреть по их запросам...А так просто скинул ссылка на "не поддерживается" и вроде не посылал, а работы стало меньше.
Работы и так меньше - в опенсорсе никто никому ничего не обязан. В том числе никто не обязан фиксить баги.
представлять ты конечно горазд, а можешь показать хоть одно письмо этих самых пользователей этим м-кам про проблемы в DSA? (Ну кроме писем шестилетней давности когда они в первый раз его сломали всем - именно потому что полезли заботиться о чужой безопастносте. Угадай что они сделали с этими письмами и почему следующие надо писать на наждачной бумаге.)В openssh ровно НОЛЬ своего кода "поддерживающего" dsa.
Ну значит появятся LibreSSH/BoringSSH/GnuSSH, если ещё не появились.
угу, и из них еще и rsa выпилят, патамушта нисисюрна (на деле потомушта ниасилили)Безусловно неумеющие ничего кроме тыренья чужих проектов опенбсдятеры, гугль со своими мнененадоивыобойдетесь и Gnu умеющие только в прокламации и поедание мо30лей это те кто смогут сделать работающую альтернативу.
> По современным меркам DSA-ключи не обеспечивают должного уровня защиты, так как используют размер закрытого ключа всего в 160 бит и хэш SHA1Какая-то безграмотная каша в новости.
1. Типичная и единственно разрешённая длина DSA-ключа в OpenSSH - 1024 бита, а не 160 битов.
2. DSA-ключ не использует хэш SHA-1. Это одна из схем аутентификации OpenSSH использует хэш SHA-1, совместно с ключом DSA.
> Какая-то безграмотная каша в новости.это в головах у якобы-разработчиков openssh - в новости вполне точный перевод оригинала.
160 - это абстрактная "estimated security strength" (данные разумеется взяты с потолка, но очень уважаемыми и другого способа сравнивать разные методики шифрования пока не придумали) а не реальное число битов.
Т.е. более чем достаточная (больше чем у 3des) для любых реалистичных применений - в остальных случаях проще использовать паяльник.
Именно так написано в оригинальном анонсе "DSA, as specified in the SSHv2 protocol, is inherently weak - being limited to a 160 bit private key and use of the SHA1 digest."