Опубликован релиз OpenSSH 10.0, открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP. Основные...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=63042
>его удаление позволит стимулировать прекращение поддержкиКакое они право имеют "стимулировать" (формировать экосистему)? Монопольное. Как Гугл и Cloudflare имеют полное право скоту навязывать. Так и эти. Помните об этом.
> Какое они право имеют "стимулировать" (формировать экосистему)?Наверное потому что они ее и создают?
Тот кто делает, тот и решает. А потpe6ляди могут только жрать с лопаты.
>позволит стимулировать прекращение поддержки DSA в других реализациях SSH и криптографических библиотекахОни уже пытаются навязывать другим проектам, к которым отношения не имеют.
> Они уже пытаются навязывать другим проектам, к которым отношения не имеют.Что это вообще значит? Они пилят свой SSH сервер и больше не хотят поддерживать DSA. Остальные вольны делать что им заблагорассудится.
Читать не умеешь? Они гордо используют своё доминирующее положение для навязывания и не скрывают этого.
Я тоже использую свое доминирующее положение, когда ребенку говорю уроки делать и чего теперь? С чего снежинки 2005 года рождения вдруг считают, что это плохо?
Они не являются папа-мамами для других SSL/TLS-проектов, в отличие от тебя. А так, это уже попахивает претензиями на монополизацию области деятельности.
Любое устаревшее и угрожающее ИБ стоит выкидывать, если алгоритм/метод/протокол потерял свою актуальность с точки зрения ИБ, то ему место на помойке/музее истории. Свободу творчества такой подход никак не ограничивает, а вот разным несознательным криминальным элементам создает проблемы.
> Читать не умеешь? Они гордо используют своё доминирующее положение для навязывания и не скрывают этого.Как они могут НАВЯЗАТЬ другим ОТСУТСТВИЕ DSA? Тео лично вломится в дом к каждому поддерживающему DSA и обоссыт его?
Очень просто. Все, кто OpenSSH используют, дропнут (просто потому что OpenSSH дропнул, а бодаться с властями - себе дороже) - и тебе придётся.
> Очень просто. Все, кто OpenSSH используют, дропнут (просто потому что OpenSSH дропнул,
> а бодаться с властями - себе дороже) - и тебе придётся.Зачем? Если где-то есть требования по списку алгоритмов, делаешь compile-time опцию для включения-выключения. В том же OpenSSH это есть.
Погодите-ка, а ведь идея-то очень неплохая...
А кто-то запретил навязывать или что? Надо сидеть в уголочке, ковырять землю и скромненько бормотать, что будешь поддерживать то, что не хочешь? Вот сам так и делай)
> Они уже пытаются навязывать другим проектам, к которым отношения не имеют.Что мешает авторам других проектов запилить и поддерживать свой патчсет для поддержки DSA в OpenSSH?
Попробую угададать - если за десять лет они не осилили добавить в свой "другой проект" каких-либо алгоритмов, кроме DSA, то им даже и думать нечего о правке кода OpenSSH.
ну так не ставь. используй другие проекты или пиши свои
> Они уже пытаются навязывать другим проектам, к которым отношения не имеют.Не-не-не, это другое проекты к ним не имеют никакого отношения))
И вот эти самые "другие проекты" могли бы или запилить свой ssh или форкнуть имеющийся - код же открыт! Но у них лапки)) Поэтому будут пользоваться тем что дают.Вообще уже стали немного напрягать местные "особенные", которые начинают что-то требовать от опенсорса. "Пачиму вы дропаете кор2duo???", "Вы абязаны поддерживать иксы!!111" и так далее.
Ребята, попуститесь! Вам никто ничего не должен. Или сами делайте, или прикройте варежку.
Так скот на то и скот что сам не докумекает. А разумных людей стимулировать не нужно, они от небезопасного неэффективного и древнего говна первые съезжают.
Помнится, был один чел не из OpenSSH, вроде гордо носивший бирку работника Google, который выложил из себя "SSH 3.0". Этот гений, который даже RFC до первых двух параграфов не прочитал и элементарные тесты не сделал, с какого-то перепугу начал заявлять, что SSH прибит гвоздями к TCP (это не правда, ssh работает на любых двух 8-битных пайпах, транспорт хоть флешка может быть), и прибил гвоздями "SSH 3.0" к QUIC.Суть басни - идите хотя бы почитайте стандарт протокола, прежде чем позорится. Вы можете согласовать аутентификацию хоть стрибогом и шифровать кузнечиком - протокол этого вообще никак не запрещает. Хотят ли челы из OpenSSH эти (и другие подозрительные или устарелые) алгоритмы у себя в проекте? Как видно, не очень. Код под открытой лицензией ISC. Захочешь - вернёшь обратно, заодно пропатчишь под новые версии.
а по-настоящему устарелых и подозрительных частей в библиотеках не нашлось за десятки лет? А, ну да, сообчество пишет, надо же хоть что-то путнее и понятное к круглой версии выкатить.
>По сравнению с алгоритмом Диффи — Хеллмана на базе эллиптических кривыхНо есть нюанс - они не считаются настолько же безопасными, насколько работа с теорией чисел. Но Национальная Безопасность (тм) в некоторых государствах считается uber alles. И ради неё могут на каких угодно разработчиков, живущих там, давление оказать.
> Но есть нюанс - они не считаются настолько же безопасными, насколько работа с теорией чисел.Простейший квартовый компьютер может взломать биткоин за неделю.
Суперкомпьютер будет взламывать это временем зарождения миллионов галактик.
>квартовыйЭто же сколько кварт надо выпить, чтобы достичь нужного эффекта!
Сказал аноним знакомый с биткойном из новостей. Не позорьтесь.
Кто вам такое сказал?
В огороде бузина.Эллиптические кривые это и есть теория чисел.
Странно... А мне говорили, что алгебраическая геометрия...
Версия для линукса бодро докладывает, что она уже р2
ssh -V
OpenSSH_10.0p2
А почему mlkem768x25519-sha256 а не sntrup761x25519-sha512?sntrup761x25519 же лучше будет, или я не прав?
Чем лучше? ML-KEM шире распространён.
С точки зрения безопасности что лучше?
https://blog.cr.yp.to/20231023-clumping.html
Толково. Спасибо.
Кому нужен DSA (как и мне для виртуалок с древними системами) - в Putty всё на месте.
В клиенте они тоже dsa выпилили? То есть на какое-нибудь hp StorageWorks зайти -- гульден? От спасибочки!
Гм. Обычно везде, где есть dsa есть и rsa жи, ни? Причем, afaik dsa нигде, кроме fips'овских железок для всякого us goverment дефолтом не был...
Что мешает держать в отдельной папочке клиент версии 9.9?
snap пакет?
Запустить клиент нужной версии в 2025 году совершенно не решаемая задача, конечно.
> задействован гибридный алгоритм обмена ключами "mlkem768x25519-sha256", стойкий к подбору на квантовом компьютереИ видимо не стойкий на обычном :)
> По сравнению с алгоритмом Диффи — Хеллмана на базе эллиптических кривых удалённая реализация медленнее и требует дополнительных вычислительных ресурсов при идентичном уровне безопасности.Вот только к элиптике есть вопросы.
> По умолчанию выставлен список приоритетов при выборе шифров: Chacha20/Poly1305, AES-GCM (128/256) и AES-CTR (128/192/256).Глупое умолчание.
AES-NI есть много где в железе а чачи нигде нет.
Более того это по сути единственный в мире чисто поточный шифр (не считая RC4 отправленного на пенсию).
> В sshd добавлена опция "--with-linux-memlock-onfault" для закрепления sshd в памяти (запрета вытеснения в раздел подкачки).Хорошо но на фре это делается банальным
sshd_oomprotect="ALL"
в rc.conf, который там внутри дёргает /usr/bin/protect для указанного PID.
Я так кучу важных сервисов на системе сделал неубиваемыми.
Хотя нет. Сделали банальный лок страниц памяти.
> Вот только к элиптике есть вопросы.Можно поподробнее?
https://kiwibyrd.org/2016/10/07/1610/Из забавных совпадений тут то, что p-256 теперь форсит везде гугол для ECDH.
Это тот кивибирд, который на 3дньюз несколько лет назад писал всякую антинаучную дичь, типа про "древне-китайские бронзовые ПРОЗРАЧНЫЕ зеркала, которые ОПРОВЕРГАЮТ СОВРЕМЕННУЮ НАУКУ"? И вы приводите его статью десятилетней давности для чего? Над вами недостаточно часто смеются?
Да автора бывает заносит.
Но в данном случае речь идёт об объективно наблюдаемых фактах:1. АНБ перестало форсить переход на элиптику своих госов. Можно интерпретировать это как: нет смысла напрягатся, скоро вместо элиптики будет что то лучше, квантово стойкое потому сплошная экономия.
2. Элиптику форсят в разных местах. Те если до 2015-18 года элиптика вполне существовала но всем было пофиг то сейчас её прямо форсят, это видно даже в этой новости.
Тот же гугол форсит именно p-256 для ECDH которую по словам кивибёрда даже NIST выкинул.3. RSA вполне надёжен, все претензии к нему только в производительности, и надо сказать что его юзали ещё в древние времена на древнем железе. А применительно к ssh (где conn rate низкий) так вообще пофиг.
> типа про "древне-китайские бронзовые ПРОЗРАЧНЫЕ зеркалаПрозрачный аллюминий же изобрели, может и до бронзы дело дойдёт :)
А касательно зеркал - так вероятно прозрачная бронза заменяла стекло.
Но из "статьи" по ссылке можно сделать вывод (точнее, автор сам его делает в конце), что "у кого надо" есть алгоритмы, которые _наверное_ могут взломать ECC без всяких квантовых компьютеров. Т.е. отказ АНБ от внедрения ECC обусловлен тем, что АНБ считает ECC небезопасным _прямо сейчас_. И, видимо, именно этим киви и пытается объяснить форс перехода к "постквантовым" алгоритмам. Но он слишком увлекается, украшая свою статью переплетениями словесных узоров и делая её похожей на индейские шёлковые ковры - настоящее произведение искусства, удивительные изделия, которые поражают воображение каждого, кто их увидит и вызывают в памяти полузабытые слова из старинных восточных сказок, услышанных от родителей ещё в детстве. Короче, я задолбался читать его поток сознания.Также из статьи видно очевидное преимущество ECC: "256-битные операции ECC эквивалентны работе с модулем длиной 3072 бита в RSA". Для меня это вполне нормальное объяснение форса этих алгоритмов везде. Шифрование теперь даже в лампочках есть, удобно, когда оно не требует больших мощностей.
>Да автора бывает заносит.
Его не заносит, он откровенно лжёт. Я уже не помню всю статью про эти зеркала, но он привёл "немагическое" объяснение этого эффекта, но потом всё равно жирно намекнул на то, что не всё так однозначно. Это был не первый раз, когда он нёс подобную дичь, но мне этот момент запомнился именно этим внезапным поворотом - он дал разумное объяснение эффекта, но тут же написал, что "это всё неправда" не приводя никаких внятных доказательств или аргументов. Собственно, после этого я перестал его читать.
Хорошо, давайте по другому.Если АНБ сказало своим госам сидеть на попе ровно с RSA, то зачем нам бегать с ECDSA/ED25519?
В остальном видно как остальных форсят в ECDSA/ED25519, так же как форсили DUAL_EC_RNG и некоторые другие алгоритмы.
Допустим для гугла есть разумные экономические обоснования форсить крипту вообще и форсить ECC даже если оно дырявое.
Но я не вижу смысла в ECC вообще для себя лично. Притом что я убил где то пол года на написание С кода ECDSA/GOST лично для себя. Впрочем то для чего я писал код - там то вполне норм ибо ценность заметно ниже цены взлома.Те лично я бы рассматривал ECC сейчас как вычислительно дешманскую крипту для которой потенциально есть средства раскрытия, но средства эти дорогие и палить их по мелочам не будут.
Для личного применения RSA с длинным ключём вполне ок, там где не предполагается частых вычислений. Вот SSH самое оно.
На вебсайт надо сильно думать: я тут на домашний выкатил RSA 16384 так потом когда сканер-проверяльщик ssl натравил видно было что nginx по пол ядра отжирают :)
> 2. Элиптику форсят в разных местах. Те если до 2015-18 года элиптика
> вполне существовала но всем было пофиг то сейчас её прямо форсят,
> это видно даже в этой новости.Ее энфорсят в основном потому что...
1) Мелкие ключи удобнее в обращении чем огромные 4096 бит чушки. Задача крипто это заменить большой секрет маленьким, по большому счету. Иначе можно просто одноразовые блокноты юзать и не париться всякой ерундой, это уж точно не ломаемы. Но увы и не очень практичны.
2) Скорость vs RSA. Не очень круто когда ремотные системы могут вызывать неиллюзорную нагрузку на сервера. Владельцам серваков это напрямую стоит денег - и подставляет их под ресурсные атаки. Как еще понятнее это объяснить? Стайка ботов легко кладет ssh с 4096 ключами наповал. Оно прсото уходит заниматься обсчетом RSA до упора и попробуй туда вообще зайти за обозримое время.> Тот же гугол форсит именно p-256 для ECDH которую по словам кивибёрда
> даже NIST выкинул.Вообще-то гугло 25519 с неких пор любит и даже заимплементили его местами. Это у вас вон то какого года сведения?
Смотри, я могу объяснить "непонятную торопливость" "инстанций" не прибегая к сиономарсианам: инстанции знают, что если они начнут сегодня, то внедрение новых технологий станет более-менее массовым как раз к тому моменту, как квантовый компьютер можно будет купить на алиэкспресс.
Смотри, у меня RSA 16384, я могу ещё долго сидеть и смотреть на крах биткойна и прочих применений элиптики :)
Это если нам про квантовые - врали. А если нет?Я вот _лично_ пытаюсь справляться с проблемами по мере их появления, заранее - только если на 146% точно предсказал где\что\как(\кто :)
Что бы там ни врали - мне с RSA 16384 без разницы, ничего не меняется :)
Как бе это сказать ... мне и с 4К (а вне работы - да и даже с 2К) - так же :)Любители играют до победы! Профессионалы - до свистка.(С)
Дадут свисток на 16К - будет и 16К ... и премия за безопасТностЕ :))))
А где вы ключ такого размера храните? На всяких security key оно вродь не лезет.
При попытке использовать для commit signing скорее всего проблемы будут - тот же gitlab пишет, что из-за go specific implementation максимальный размер 8мб.
Предполагаю, что и еще где-нибудь споткнуться можно - и вот нахрена?
> Смотри, у меня RSA 16384, я могу ещё долго сидеть и смотреть
> на крах биткойна и прочих применений элиптики :)Поэтому реально тебя покрашит первый забредщий бот - прогрузив системы счетом этого RSA в полку. Для ssh конечно можно гемор типа порткнока устроить, но это икнется удобством его использования с 1 стороны. И все равно не понятно что делать с сервисами которые публично доступны? Можете поставить счет RSA-16384 своему веб серверу. А мы так и быть посмотрим - сколько операций в секунду эта штука вообще потянет, и завалит этого дино нахрен - вон тот смартфон на тощем линке, или нет?! :)
p-256 классифицирован DJB как небезопасный: https://safecurves.cr.yp.to/#:~:text=The%20following�...
DJB тот ещё фрукт: везде бегал и орал про ужасный ECDSA только потому что там тайминг атаки неустранимы, чтобы пропеарить свой 25519.Да и список далеко не полный, там и от ниста не всё и от браинпула, и госта нет.
> И видимо не стойкий на обычном :)Кажеться, они совмещают "на всякий случай". Там логика типа, алгоритм новый, хз как он, так что сделаем и так и сяк, и если взломают, то хоть старый уровень останется.
Если бы не стойкий на обычном, то на обычном ломали бы квантовую часть, а на квантовом обычную. Ну в таком плане.
> Глупое умолчание.
Слыхал, в имплементации gcm что-то там не шифровалось, типа метаданных каких-то или что-то такого плана.
> Chacha20-poly1305 is preferred over AES-GCM because the SSH protocol does not encrypt message sizes when GCM (or EtM) is in use. This allows some traffic analysis even without decrypting the data. We will deal with that soon.
http://kb.ictbanking.net/article.php?id=691
Также, раньше на мобилках было плохо с аппаратной поддержкой.
https://blog.cloudflare.com/do-the-chacha-better-mobile-perf.../Ну и кто-то говрит, что он чуть безопастнее типа:
https://www.reddit.com/r/cybersecurity/comments/gxso79/chach.../
>Ну и кто-то говрит, что он чуть безопастнее типа:
>https://www.reddit.com/r/cybersecurity/comments/gxso79/chach.../Еще более авторитетно получится, когда на Реддите будут ссылаться на анонимусов с Опеннета.
> Кажеться, они совмещают "на всякий случай".На всякий случай квантовых с нужным кубитом ещё нет, даже для банальных ECDSA на 96, 128 бит которые задепрекейтили ещё лет 15 назад.
А для аналогов с RSA ещё очень долго не будет хватать кубитов.
> Chacha20-poly1305 is preferred over AES-GCM because the SSH protocol does not encrypt message sizes when GCM (or EtM) is in use. This allows some traffic analysis even without decrypting the data.Да и пофиг.
> Также, раньше на мобилках было плохо с аппаратной поддержкой.А мне и не надо чтобы ко мне с мобилок ходили и гоняли джигабайты трайфика :)
Для мобилок гугл чачу форсил, чтобы ютуп смотреть приватно.В остальном же я вполне себе монтирую через sshfs диски и гоняю относительно много трафика поэтому для меня разница между AES и чачей будет заметна.
С мобилки же если и сижу в ссш - то это терминал, где хоть тормозным гостом можно шифровать - ничего не изменится.
> Ну и кто-то говрит, что он чуть безопастнее типаПусть говорят, мне AES-256 хватает.
>> Chacha20-poly1305 is preferred over AES-GCM because the SSH protocol does not encrypt message sizes when GCM (or EtM) is in use.
> Да и пофигНифига себе "пофиг". Размер пакета в сообщении SSH, если что, относится к незашифрованным реальным данным. Размер дополнительного рандомного паддинга идёт ещё одним байтом. Зная размер плейнтекста, можно, например, угадать, чем конкретно вы сейчас занимаетесь/ печатая что-то у себя в консоли и смотря что консоль возвращает обратно. Поэтому размер плейна тоже должен шифроваться. Странно, что GCM этого не делает, ибо протокол обязует размер пакета добивать до минимума размера блока шифрования, чтобы можно было зашифровать вообще всё, включая длину плейнтекста.
Как видишь это почему то никого не волнует.
Я вижу то, что никто даже конфиг ssh (клиента) не трогает, чтобы себе жизнь упростить всякими hostkeyalias и match, не говоря уже о том, что никто не трогает дефолтный sshd_config. А если никто этого не делает, значит по дефолту у всех и так чача и ed25519.
> Странно, что GCM этого не делает, ибо протокол обязует размер пакета добивать до минимума размера блока шифрования, чтобы можно было зашифровать вообще всё, включая длину плейнтекста.Это не GCM должен делать, написано ведь "because the SSH protocol does not encrypt message sizes when GCM (or EtM) is in use".
GCM это режим блочного шифрования, и там "обязует размер пакета добивать до минимума размера блока шифрования" это относится к самому алгоритму блочного шифрования, который не будет ничего шифровать меньше необходимого размера блока данных.
И конечно же любая метаинфа связанная с плейнтекстом также должна быть конфиденциальна.
Новость не новая, мб исправили.> Это не GCM должен делать, написано ведь
Да, но для нас, как для пользователей, этого можно грубо списать как: алгоритм не реализован в ssh, а за вычетом его остается aes-ctr и чача.
> На всякий случай квантовых с нужным кубитом ещё нет, даже для банальных ECDSAЭто понятно. Тут речь о будущем... Хах, хотя, какое тут будущее))
И есть слухи, что некоторые государства сохраняют шифрованные данные с целью расшифровать, если будут найдены уязвимости в определенных алгоритмах или грубая сила позволит.
> С мобилки же если и сижу в ссш - то это терминал, где хоть тормозным гостом можно шифровать - ничего не изменится.
Ну это ваш случай. У меня в одном заведении фаервол с белым список по доменам, так что использую ssh как forward proxy, как раз с мобилки.
> Это понятно. Тут речь о будущем... Хах, хотя, какое тут будущее))Гибрид
> есть слухиhttps://en.m.wikipedia.org/wiki/Utah_Data_Center
https://en.m.wikipedia.org/wiki/SORM
>И видимоНет.
>Вот только к элиптике есть вопросы.
Задавать их вы, конечно, не будете, потому слабо понимаете, о чём говорите.
>а чачи нигде нет.
Есть даже в смартфонах.
> Задавать их вы, конечно, не будете, потому слабо понимаете, о чём говорите.Ээээ...вообще то вы это пишете одному из немногих авторов собственной имплементации ECDSA+GOST на C на этой планете. И когда я писал свою - остальных реализаций было штук 5, в основном по криптолибам.
Те она полностью на С, начиная со своей реализации длинных чисел и операций над ними, продолжая математикой над кривыми и заканчивая собственно применением этого всего для криптографии.
Не буду спорить, я математическую часть/суть не понимаю и только имплементировал алгоритмы.
Однако заявлять что я совсем не разбираюсь в теме слишком высокомерно с вашей стороны.
> Есть даже в смартфонах.Где где!?
Речь про железо вообще то.
А так то это и на счётах+бумаге можно посчитать и сказать что даже в каменном веке могли в чачу.
Если вы такой спец по реализации, где ВАШ список вопросов к эллиптике? Основанный на математике, а не на теории заговоров.
В прошлом, там же где и ECDSA и 25519 и прочая элиптика.
Накодить что-то по чужим алгоритмам и разрабатывать эти алгоритмы — большая разница.> Не буду спорить, я математическую часть/суть не понимаю и только имплементировал алгоритмы.
> Однако заявлять что я совсем не разбираюсь в теме слишком высокомерно с вашей стороны.Высокомерно — это с твоей стороны делать вид, что ты разбираешься в чём-то кроме кодинга на С.
> Ээээ...вообще то вы это пишете одному из немногих авторов
> собственной имплементации ECDSA+GOSTСуперкомбо, 10 из 10. И сколько известных криптографов почтило ваше нечто своим аудитом? Имена оных вы, конечно, назовете? Как пруф что это вообще стоит внимания?
> остальных реализаций было штук 5, в основном по криптолибам.
И опять же - сколько из них известных криптографов встерчало? Чтобы хотя-бы базовые факапы проверить, типа утечек таймингов, очевидных факапов крипто и проч? Хотя ECDSA + GOST конечно да, мало кто захочет в мутные схемы вписываться, явно провальное занятие для репутаци.
> Не буду спорить, я математическую часть/суть не понимаю и только имплементировал алгоритмы.
При том я думаю что информационную безопасность и требования к криптографическому коду, особенно в современном мире - вы тоже не понимаете. И поэтому есть довольно высокая вероятность что ваш код - кусок грабель. При том вы их любезно раскладываете другим и гордитесь этим.
> Однако заявлять что я совсем не разбираюсь в теме слишком высокомерно с
> вашей стороны.Я другой анон, но скажу что мне не нравится ваше соотношение уровня экспертизы и нахрапа с которым вы вашу точку зрения двигаете. Это - некомпетентно.
> Речь про железо вообще то.
Со своей стороны я нахожу очень странной идею наезжать на эллиптику с 1 стороны и при этом слепо доверять хардварной реализации без сорца - с другой. Это очень кривая точка зрения с двойными стандартами.
> А так то это и на счётах+бумаге можно посчитать и сказать что
> даже в каменном веке могли в чачу.Могли. Но реально практиковали какой-нибудь шифр Цезаря.
> И видимо не стойкий на обычном :)Поэтому вон те юзают ДВА алго... вот как раз на этот случай, как я понимаю.
> Вот только к элиптике есть вопросы.
К RSA тоже вопросы есть. И дофига. При том намного больше чем к нормальной эллиптике типа 25519 какого. Там есть и подставы с экспонентами, и возможность слабых ключей, тайминг атаки, возможность ресурсных атак "совсем не в пользу сервера", огромные ключи которые неудобно передавать и использовать и нужно отдельное дупло для них и проч.
> Глупое умолчание.
> AES-NI есть много где в железе а чачи нигде нет.Охрененно. Человек рассказывает про вопросы к эллиптике, но вопросов к железу у него нет. Все что надо знать о секурити экспертах опеннета.
> Более того это по сути единственный в мире чисто поточный шифр (не
> считая RC4 отправленного на пенсию).В каком бы это месте AES - поточный?! Вы там совсем того? Что AES что chacha на самом деле так то блочные по своему дизайну. И из блочного варианта можно всегда поточный сделать, вопрос спеков и утрясания alignment. И только.
> Хорошо но на фре это делается банальным sshd_oomprotect="ALL"
Это запрещает именно выгрузку в своп? Или таки убиение по oom? Потому что с свопом проблема например в том что там могут допустим ключи осесть. И проч. И потом можно у кого-то очень неожиданно для него ключи потырить, допустим.
> в rc.conf, который там внутри дёргает /usr/bin/protect для указанного PID.
Нихрена себе спагетти системного менеджмента.
> Я так кучу важных сервисов на системе сделал неубиваемыми.
Есть довольно большая разница между "неубиваемым" и "не сохраняет ключи на диск".
> Хотя нет. Сделали банальный лок страниц памяти.
А еще кое кто конкретно блеснул экспертизой. К сожалению - со знаком минус. И увы, это для вас становится трендом. ИМХО Вы в крипто и безопсности нифига не понимаете и учитывать ваше мнение - не следует.
Как они задолбали удалять старые алгоритмы, особенно из клиента. Ну не добавить в старые железки новые алгоритмы, никак. Putty в этом плане намного лояльнее, но его применение ограничено, конечно.
Да оспыдя. Пока это обновление до LTS'а доползет - те железки уж сдохнуть успеют. А если и останется 2,5 штуки, умеющие в dsa, но не умеющие в rsa - то какой-нибудь dropbear вроде не отбирают пока...
1. держать в отдельной папке старую версию с нужным протоколом.
2. в пакетманагере прибить гвоздями нужную старую версию для всей системы.
> в пакетманагере прибить гвоздями нужную старую версию для всей системыИ вручную накладывать бэкпорт патчи с заплатками CVE
а там, куда без DSA не зайти, всё типа до сих пор получает обновления или там даже вручную не наложить, так что норм?
> Putty в этом плане намного лояльнееЭто клиент, а не сервер. Клиентам, как раз важно поддерживать бесконечно любое легаси.
PS: и вам в винду уже давно Microsoft завезла нормальный SSH клиент и терминал, вам для SSH, PuTTY не нужен, вы просто используете его по энерции, потому что кто-то когда-то так вам сказал работать
PS2: если вам нужна поддержка легаси на SSH сервере, то с помощью Docker вы всегда можете поднять SSH сервер любой версии не ломая свою систему, но Docker это же не для вас, да?
>с помощью Docker вы всегда можете поднять SSH сервер любой версии не ломая свою систему, но Docker это же не для вас, да?С незакрытыми уязвимостями, но безопасность это же не для вас, да?
> С незакрытыми уязвимостями, но безопасность это же не для вас, да?причём тут уязвимости? речь об избежании прдолинга с бекпортами и прочими трюками, лишь бы не осваивать контейнеры
Ну а снизить риск от уязвимостей можно разными средствами, включая PoLP, MAC, DAC и т.п.
Из помойк^W контейнера вылезать как будете, чтобы систему настраивать? Или оно вам только как транспорт нужно? В первом случае это маразм, потому что вам так или иначе нужен рут, чтобы хоть что-то адекватное делать. Во втором случае вы можете запускать sshd в непривилегированном режиме, и всего делов. Даже для tun рут не нужен. Только придётся отказаться от PAM аутентификации, потому что еяпп оно рута требует.
> В первом случае это маразм, потому что вам так или иначе нужен рутпод рутом подключаться, вот это настоящий маразм, подключение под рутом нужно сразу отключать везде
> Или оно вам только как транспорт нужно?
это только ограничивается вашей фантазией, тут непаханное поле для применения
> Только придётся отказаться от PAM аутентификации, потому что еяпп оно рута требует.
нет, тоже прикрутить можно
>и вам в винду уже давно Microsoft завезла нормальный SSH клиент и терминал, вам для SSH, PuTTY не нужен, вы просто используете его по энерции, потому что кто-то когда-то так вам сказал работатьНу ок, как в нормальном терминале сделать разные шрифты и цвет разным хостам? Вот чтобы прямо тут разделить тест и прод?
> Ну ок, как в нормальном терминале сделать разные шрифты и цвет разным
> хостам? Вот чтобы прямо тут разделить тест и прод?Через профили в settings.json. Например:
```
{
"profiles": {
"list": [
{
"guid": "{guid-for-test}",
"name": "Test Environment",
"commandline": "ssh user@test-host",
"font": {
"face": "Cascadia Code NF"
},
"colorScheme": "One Half Light"
},
{
"guid": "{guid-for-prod}",
"name": "Production Environment",
"commandline": "ssh user@prod-host",
"font": {
"face": "Fira Code"
},
"colorScheme": "One Half Dark"
}
]
}
}
```Это удобнее, чем тыкаться по менюхам и подменюхам в GUI из 90-х, как в PuTTY и многих маразматических Windows программках. Открываете файл в редакторе кода и документацию на сайте Microsoft, изменения подхватываются на лету. Менюхи, подменюхи в стиле винды для старпёров (не по возрасту, а по менталитету, можно в любом возрасте быть старпёром), отвыкайте от них.
И это не единственный способ, другие просто не именно для Windows Terminal, а вообще для SSH и оболочек командной строки.
> В ssh-keygen добавлена поддержка токенов FIDO, не возвращающих данные аттестации, таких как WinHello.Гм. Оно ж с 8.9 в 10ке работает - ssh-keygen -t ecdsa-sk и нерезидентный ключик зашифрованный TPM'ом с аутентификацией по морде\пальцу\чему-изволите вот прям из коробки. Еще помнится смеялись про "тот неловкий момент, когда под windows SSH работает лучше, чем под онтопик", в котором это делалось традиционно через пляж-гамак-лыжи-pkcs11...
Ну и как оно, при использовании StrictHostKeyChecking=no по-прежнему добавляет никак не проверенные ключи в known_hosts?
Так не пользуйтесь "no". Какие проблемы? Там "ask" по-умолчанию.
> Так не пользуйтесь "no". Какие проблемы? Там "ask" по-умолчанию.У меня комп для тестов, у которого при каждом ребуте новый ключ, ради чего мне там ask делать? Чтоб потом удалять его?
Вы зачем эту опцию используете? Почитайте в манпейдже про HostkeyAlias, если вам нужно подключаться к одной и той же тачке разными способами. Вместо хоста в known_hosts будет сохранятся этот самый альяс, и никаких предупреждений о новом хосте / сменившемся на 192.168.0.2 ключе вы не увидете больше никогда.
> Вы зачем эту опцию используете? Почитайте в манпейдже про HostkeyAlias, если вамОпция интересная, но не мой случай, у меня тестовая машина загружается каждый раз с новыми ключами и при выключении удаляется.
Опция поможет только если бы я на разные хосты через один IP:port ходил.
Доктор! Если я делаю "вот так!" - мне больно!
... а вы "вот так!" - не делайте :)
То есть Вы отключаете проверку ключей, и ужасно возмущены тем, что ключи после этого не проверяются? Никаких противоречий не замечаете?
Нет, я возмущён тем, что непроверенный ключ сохраняется туда же, куда и проверенные. Неужели из предыдущих сообщений это никак не читается?
Совершенно никак и не читается, а со стороны выглядит именно так, как я описал. А в вашем случае - установите для этого хоста отдельный known_hosts, опцией UserKnownHostsFile. И там уж выбирайте хоть /dev/null.А то поведение, что вы описали, является ожидаемым, и никак не является ошибкой.
Ожидать что ключи разного качества проверки валятся в одну кучу? Я простите трезвым за комп сажусь, а не после двух литров пива, чтоб такое "ожидать".Как раз наоборот, если после такого подключения попытаться на тот же хост зайти уже с ВКЛЮЧЕННОЙ проверкой ключа, при текущем состоянии софта произойдёт вход, считая что тот ключ, который уже сохранился КАК БЫ УЖЕ ПРОВЕРЕН (хотя никто его не проверял), что точно не является ожидаемым. И тут даже никаких бла-бла-бла про ожидаемое-неожидаемое не нужно - софтине сказали проверить ключ, а она этого не сделала.
Впрочем, вы похоже просто не понимаете о чём речь (так же как и не смогли понять смысл предыдущих сообщений) - потому что судя по всему рассуждаете на уровне тестировщика, а проблема архитектурная.
Это не архитектурная проблема, а просто несоответствие между вашими ожиданиями и фактическим поведением. Согласен, что фактические поведение не интуитивно, но оно документировано.
Вам верно ответили, что вопрос решается StrictHostKeyChecking=no совместно с опцией UserKnownHostsFile none.
Уважаемый, я знаю без ваших или его рекомендаций, как обойти этот косяк.
Но то, что у меня есть изолента для того, чтобы залепить дырку не означает, что дырки нет.
Хотя в вашем мировоззрении, наверное, означает.