Опубликован релиз OpenSSH 9.8, открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP. Помимо устранения отдельно анонсированной критической уязвимости (CVE-2024-6387), позволяющей добиться удалённого выполнения кода с правами root на стадии до прохождения аутентификации, в новой версии исправлена ещё одна менее опасная уязвимость и предложено несколько существенных изменений, нацеленных на повышение безопасности...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61473
И как таперь к старым linux'ам подключаться?
Я, видимо, пропустил, а где пишут, что старые линуксы не будут работать? И что подразумевается под старостью?
даже к старым линуксам могут подключаться одновременно несколько человек. не жадничайте!
По telnet
А как сейчас подключаетесь?
Используя SHA-1, потому что других алгосов там нет, и старые версии не отличают шифрование ключа от алгоса подписи ключа.
> И как таперь к старым linux'ам подключаться?Используя такой же старый linux :)
А зачем в принципе передавать именно нажатия при авторизации? Разве не проще собрать строку пароля на стороне клиента и попросту отправить её целиком? Либо, раз уж такая особенность протокола и парольной авторизации, то опять же набирать в буфер и передавать пачкой все нажатия, как какой-нибудь парольный менеждер. Разве остались ситуации, где требуется такой контроль ввода? Даже если подключить OTP, то это всё равно отправка другой такой же строки в большинстве случаев.
Потому что помимо ввода пароля существует обычная работа с консолью. А там удобнее чтобы работало как с обычным терминалом чем присылался текст и не известно как целевая машина будет работать с этим текстом. А тут если сказали ентер значит ентер, а не текст "нажат ентер". Но злые языки конечно знают что первичной целью был конечно же фингерпринтинг.
Ввод пароля происходит явно ДО открытия сессии, т.е. это уж точно не "обычная" работа с консолью.
И это не говоря о том, что все время думал что по сети летит хэш, а не сам пароль
Зачем хэш, это же закрытыи канал?
А зачем слать пароль, если сравнивать все равно будет с хэшем из shadow/..?
Плюс это практика проверенная десятилетиями
моя неправда:
согласно rfc https://datatracker.ietf.org/doc/html/rfc4252#section-8
вполне может быть и plaintext
с предварительной конвертацией и нормализацией при необходимости.
> Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8.в любом случае все это (логин, пароль) уходит одним пакетом, а не по нажатию каждой клавиши (с таймаутaми)
т.е. никакого «передавать именно нажатия при авторизации» не происходит — с чего ветка обсуждения и началась
Какой хэш? В зависимости от настроек pam на принимающей стороне может быть различный способ проверки пароля. /etc/shadow, ldap, свой велосипед и т.д.
1. метод хеширования хранится вместе с хэшем в самом его начале, так называемый prefix (man 5 crypt).
Формат примерно такой - $y$…………:
$1$: MD5, $5$: SHA-256, $6$: SHA-512 sha512crypt, $gy$: gost-yescrypt, $y$: yescrypt
…
В современных бэкэндах (/etc/shadow, ldap, samba) хэши сохраняются именно в таком формате.
Хранение самого пароля в планарном виде считается моветоном.2. Так что передавать по сети сам пароль нет необходимости, достаточно договорится о методе хэширования (что обычно и происходит)
3. И да, в ssh может(!) передаваться логин/пароль открыто , о чем я и написал выше в #21.
Но это не имеет отношения к тому что обсуждали, потому что все равно идет одним пакетом, а не пакет на каждое нажатие клавиши
> 1. метод хеширования хранится вместе с хэшем в самом его начале, так
> называемый prefix (man 5 crypt).
> Формат примерно такой - $y$…………:
> $1$: MD5, $5$: SHA-256, $6$: SHA-512 sha512crypt, $gy$: gost-yescrypt, $y$: yescryptЭто просто id хэша, далее там ещё salt идёт. Но это здесь не важно. Потому как это справедливо только для shadow и т.п.
> …
> В современных бэкэндах (/etc/shadow, ldap, samba) хэши сохраняются именно в таком формате.А в ldap и mysql хранится так, как захочет соответсвующая pam-либа. Там другой формат может быть.
> Хранение самого пароля в планарном виде считается моветоном.Что такое "планарный вид"? Чистый вид? Никто и не говорит про хранение в таком виде. Речь идёт про передачу внутри защищённого канала во время аутентификации.
> 2. Так что передавать по сети сам пароль нет необходимости, достаточно договорится
> о методе хэширования (что обычно и происходит)Не всегда. Есть всякие сложные схемы аутентификации (читай про gssapi и kerberos). И насколько я знаю, ничего такого при передаче пароля не происходит - он идёт чистым по зашифрованному каналу. По крайне мере раньше так было. И это адекватно. Потому как, если я захочу использвать у себя какой-нибудь распоследний blake3 для хранения хэшей паролей, а на машине с ssh-клиентом этого нет, то всё что ли? Финита ля комедия. Зайти не сможем.
разумеется вы можете использовать все что угодно, хоть свой pam-модуль написать
но чтобы это работало именно с ssh, нужно чтобы он поддерживал передачу именно пароля
(и была включена поддержка pam - man sshd_config)
проверить можно как-то так (во 2 строке - available SSH authentication methods):
> $ ssh -o PreferredAuthentications=none -o NoHostAuthenticationForLocalhost=yes localhost
> test@localhost: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
> или
> $ ssh -p 222 -o PreferredAuthentications=none -o NoHostAuthenticationForLocalhost=yes localhost
> test@localhost: Permission denied (publickey,keyboard-interactive).
> А в ldap и mysql хранится так, как захочет соответсвующая pam-либа. Там другой формат может быть.не либа, а тот, кто это всё настраивал :D
может, но для этого придется собрать свою, «уникальную» во всех отношениях конфигурацию (аля 90-е)
именно поэтому в samba придумали "samba-tool user getpassword --decrypt-samba-gpg" и с AD это не прокатит - keytab file придумали не просто так.И вообще, о чем вы спорите то?
> Речь идёт про передачу внутри защищённого канала во время аутентификациида, если вы так настроите свою систему - свободу творчества никто не отменял
> разумеется вы можете использовать все что угодно, хоть свой pam-модуль написать
> но чтобы это работало именно с ssh, нужно чтобы он поддерживал передачу
> именно пароляОн это давно поддерживает :-). Вряд ли найдётся много современных установок sshd без UsePAM yes в конфиге. Это просто не удобно. Про передачу пароля - ну об этом, вроде, и речь изначально. Странно было бы обсуждать случай с передачей пароля без активации аутентификации по паролю на стороне sshd, не так ли?
> не либа, а тот, кто это всё настраивал :D
В смысле не либа? А что организует проверку пользователя/пароля на стороне sshd? Различные pam-модули - .so-файлы. Плагины, модули - пофигу как назвать. Это либа, которая связывается налету с программой.
> И вообще, о чем вы спорите то?
О том, что пароль передаётся в чистом виде и уже на стороне sshd проверяется pam'ом по выбранной схеме. Вот о чём. И помоему это очевидно настолько, что не понятно о чём тут спорить. sshd понятия не имеет какая схема хранения паролей и не должен. В этом смысл pam.
В ответ на:
"И это не говоря о том, что все время думал что по сети летит хэш, а не сам пароль"
и
"А зачем слать пароль, если сравнивать все равно будет с хэшем из shadow/..?"
> Про передачу пароля - ну об этом, вроде, и речь изначально.нет. про передачу нажатия клавиш
остальное - переливание из пустого в порожнее
>> Про передачу пароля - ну об этом, вроде, и речь изначально.
> нет. про передачу нажатия клавишЗначит показалось и это:
"А зачем слать пароль, если сравнивать все равно будет с хэшем из shadow/..?"
кто-то другой писал.
> остальное - переливание из пустого в порожнее
Это я уже заметил :-).
Речь о паролях, передаваемых внутри сессии, "например, при вводе паролей в su или sudo." А при парольной аутентификации в самом SSH, да, обычно (кроме редко используемого режима keyboard-interactive) пароль передается одной строкой. С этим тоже когда-то была уязвимость - можно было определить длину пароля, см. https://www.openwall.com/articles/SSH-Traffic-Analysis
А чего в эту тему не написали ссылку про связи опенбзд с ФБР? https://www.opennet.dev/opennews/art.shtml?num=28998
2010? Вовремя откопали.
Вынести бы ещё весь функционал в библиотеку, чтобы отпала необходимость в libssh/libssh2.
Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании dsa, но убирать совсем - идиоты.
> Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со
> своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании
> dsa, но убирать совсем - идиоты.Так подключайся к старым коммутаторм старой версией либы.
Они же не удалили предыдущие версии.
А то тебе послушать - сидели бы до сих пор на первопне
>> Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со
>> своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании
>> dsa, но убирать совсем - идиоты.
> Так подключайся к старым коммутаторм старой версией либы.
> Они же не удалили предыдущие версии.
> А то тебе послушать - сидели бы до сих пор на первопнеДа ты ж моё золото. А где взять эту старую версию на новом дистре?
./configure
make
> ./configure
> makeНу я почему-то другого и не ожидал. Спасибо, не надо.
Ну, я, помню, какое-то время поддерживал ppa для openssl+alpn+nginx - пока не подошел EOL для дистрибутивов, где это было актуально. Можете точно так же поддерживать пакеты для своего любимого дистрибутива.А если по простому, то не вижу проблем, если make install в какой-нибудь /opt.
> Ну, я, помню, какое-то время поддерживал ppa для openssl+alpn+nginx - пока не
> подошел EOL для дистрибутивов, где это было актуально. Можете точно так
> же поддерживать пакеты для своего любимого дистрибутива.
> А если по простому, то не вижу проблем, если make install в
> какой-нибудь /opt.Я уже понял, что не видишь. А они есть, между тем. Буквально через пару новых версий gcc/glibc/anylib старые проекты перестают собираться и их приходится править самому и это не всегда тривиально. У меня достаточно плясок с ./configure && make install на разных машинах по различным причинам на регулярной основе и так. Ещё +1 к этому списку никакого желания получать нет.
у системного администратора
> Да ты ж моё золото. А где взять эту старую версию на новом дистре?Возьми старый дистр. Заодно как раз разломают и тебя и коммутатор чтобы 2 раза не вставать.
> Возьми старый дистр. Заодно как раз разломают и тебя и коммутатор чтобы
> 2 раза не вставать.Какой старый? Куда я тебе его поставлю? Как на новые тогда ходить коммутаторы? Как их сломают через ssh, когда управление через отдельный vlan?
> Какой старый?Любой, по вкусу.
> Куда я тебе его поставлю?
Да куда угодно. На правах кэпа: на виртуалку!
> Как на новые тогда ходить коммутаторы?
Допустим из соседней виртуалки. А, это у эксперта мирового класса видимо нерешаемая задача? Ну тогда это вообще к вашему манагеру вопросы, зачем им такие овощи с таким скилом, не способные решить простейшую проблему.
> Как их сломают через ssh, когда управление через отдельный vlan?
Вы так железно уверены что у вас там в вашем уютном интранетикеводится? Судя по тупым вопросам это напрасная уверенность.
> Вы так железно уверены что у вас там в вашем уютном интранетикеводится?
> Судя по тупым вопросам это напрасная уверенность.Судя по тому, что ты пишешь, тупой здесь только ты. Уверены, не уверены - что ты за чушь пишешь? Какие нахрен ВМ? Один ./configure && make предлагает, другой тьму ВМ городить, между которыми потом бегать, что бы найти ту, которая нужна для конкретного коммутатора. Что за бред? Вы, вообще, сами хоть раз что-то подобное делали с поддержкой этого самого в несколько лет хотя бы? Ты хоть понимаешь, что это гемор? А учитывая, что о том, что ты уже не можешь попасть на коммутатор ты узнаёшь когда на него надо срочно зайти, это вообще пипец. Ты понимаешь, что ты пишешь чушь? Ты серьёзно предполагаешь, что у провайдера больше проблем/дел нет, как играться с установкой и поддержкой разных версий ssh? Откуда вы такие вылупляетесь, вообще...
> у провайдера больше проблем/дел нет, как играться с установкой и поддержкой разных версий ssh?наймите кого-нибудь кто умеет. 7000 руб/час норм оплата.
Оставь одну старую версию. Сделай тунель куда тебе надо, ходи через него. С ВМ, без ВМ. Докер себе сделай, если виртуалка для тебя - много ресурсов. Чего кричать то? Почему DSA убрали, в новости написали - не хотят поддерживать старое днище.
> Судя по тому, что ты пишешь, тупой здесь только ты. Уверены, не
> уверены - что ты за чушь пишешь? Какие нахрен ВМ? Один
> ./configure && make предлагает, другой тьму ВМ городить,А в чем проблема? У нормальных админов это streamlined, вкатить нужное дистро на энную виртуалку не займет много времени. Более того, с этой задачей накрайняк справится даже копеечный джун за несколько часов, даже если он не умеет ничего кроме next-next-next. После чего копии этой VM надолго решат ту траблу в масштабах хоть целой корпорации.
А если у вас IT департамент в дауне настолько что не может такую простую проблему решить, очевидно это вопрос к менеджменту. На тему увольнения оттуда с треском всяких нерюхов которые не могут даже проблемы уровня нулевого джуна разрулить и вместо этого - пускают пузыри, да еще смеют такой уровень на публику казать.
> бегать, что бы найти ту, которая нужна для конкретного коммутатора.
Видимо этим, с пальмы, никто не сказал что можно запускать более 1 VM и бегать никуда не придется.
> Что за бред? Вы, вообще, сами хоть раз что-то подобное делали с
> поддержкой этого самого в несколько лет хотя бы?Прямо сейчас у меня запущено на вот этом воркстейшне около дюжины VM. И одна из причин это делать в том числе и изолирование разных рабочих и хобийных проектов друг от друга. Так что даже если что-то разнесут злые хакеры, урон ограничится только пострадавшим проектом. А остальное они вообще никогда не увидят. Да и атака будет скомпенсирована сносом VM или откатом снапшота. Сильно быстрее чем то что вы там могли изобразить в таких случаях.
> Ты хоть понимаешь, что это гемор?
Я понимаю что есть те кто не умеет в современный менеджмент инфраструктуры и эффективные подходы. Виртуалку под внутренние нужды можно даже не апдейтить особо и проч, только слушающие сервисы придушить. Хуже чем DSA и SSH лохматой версии все равно не станет, а в самом пиковом случае урон ограничен этой VM и тем что с нее менеджилось. А не вообще всем, от и до.
> А учитывая, что о том, что ты уже не можешь попасть на коммутатор ты узнаёшь
> когда на него надо срочно зайти, это вообще пипец. Ты понимаешь, что ты пишешь чушь?Я понимаю что у вас вашей чудной инсталяции з@дница с менеджментом и инфраструктурой, если все работает вот так.
> Ты серьёзно предполагаешь, что у провайдера больше проблем/дел нет, как играться
> с установкой и поддержкой разных версий ssh? Откуда вы такие вылупляетесь, вообще...А у вас еще и выбор, типа, будет? Кто же это вам за свой счет вашу некромансию то будет вечно оплачивать? Мир ради на вас не встанет на паузу. И вам как-то придется адаптироваться к изменчивости оного. Если вы не можете - чтож, то что не может адаптироваться к изменениям, вымирает. Так было миллиарды лет. Так есть. Так будет. Возможно, вы просто ошибка эволюции. Но этот мир жесток. Никаких скидок. Не можете адаптироваться - гудбай, динос.
>> бегать, что бы найти ту, которая нужна для конкретного коммутатора.
> Видимо этим, с пальмы, никто не сказал что можно запускать более 1
> VM и бегать никуда не придется.Ох... Даже не знаю смеяться или плакать. Я об этом и писал, что бегать между ВМ или контейнерами это гемор, когда нужно быстро попасть на железку. Что ж вы такие буквальные-то все... Я уже писал, что узнаешь ты о том, что не можешь попасть на какую-то железку как раз в тот момент, когда на неё нужно сейчас же зайти и некогда устраивать пляски с make и новой ВМ/контейнером. Но тут понабежали админы localhost'а, которые никогда не поддерживали подобную инфраструктуру с костылями годами и не знают что это такое, и начали меня смешить какими-то очевидными вещами. Вроде, "надо ./configure && make" или "да просто ВМ поставь". Пипец.
>> Что за бред? Вы, вообще, сами хоть раз что-то подобное делали с
>> поддержкой этого самого в несколько лет хотя бы?
> Прямо сейчас у меня запущено на вот этом воркстейшне около дюжины VM.
> И одна из причин это делать в том числе и изолирование
> разных рабочих и хобийных проектов друг от друга. Так что даже
> если что-то разнесут злые хакеры, урон ограничится только пострадавшим проектом. А
> остальное они вообще никогда не увидят. Да и атака будет скомпенсирована
> сносом VM или откатом снапшота.О, господи...
> А у вас еще и выбор, типа, будет? Кто же это вам
> за свой счет вашу некромансию то будет вечно оплачивать? Мир ради
> на вас не встанет на паузу. И вам как-то придется адаптироваться
> к изменчивости оного. Если вы не можете - чтож, то что
> не может адаптироваться к изменениям, вымирает. Так было миллиарды лет. Так
> есть. Так будет. Возможно, вы просто ошибка эволюции. Но этот мир
> жесток. Никаких скидок. Не можете адаптироваться - гудбай, динос.Вот тебе это писать-то не лень было? Ты так и не понял о чём речь даже. Ты понимаешь хоть, что тут как бы речь про ответственность? ssh уже давно считается неким стандартом для входа на всякие железки. И он там нихера не обновляется как это себе могут представлять разрабы openssh. И хорошо бы у владельца такой железки иметь возможность на неё попасть и через 5 и через 10 лет. И поэтому, если авторам openssh моча в голову ударила, что что-то не безопасно, то стоит просто об этом написать при попытке соединиться с вопросом "Proceed (y/N)", а не лишать владельцев железки возможности на неё зайти. Это уже чуть больше, чем вопрос безопасности. Ты понимаешь это?
Давить вендора чтоб обновил софт коммутатора.
> Давить вендора чтоб обновил софт коммутатора.Да это только в теории работает. Если баги в старых моделях фиксят, то уже спасибо. А какой-то там ssh, не влияющий на основную работу железки - забьют. Мы уже, в принципе, идём потихоньку к тому, что бы ходить на коммутаторы через telnet. Учитывая, что управлящий vlan огорожен от всего остального, это адекватный выход. Потому как ~/.ssh/config с исключениями для шифров по ip ширится от года к году.
Сделайте Docker контейнер со старым Линуксом для этой цели, делов-то...
Хакеры и солонки
>Данные о нажатиях позволяютснимать биометрию пользователя.
> Таким образом исполняемый файл sshd теперь содержит минимальную функциональность, необходимую для приёма нового сетевого соединения и запуска sshd-session для обработки сеанса.Выглядит как можно заменить на socket activation unit [в системд] над sshd-session, такая же минимальная функциональность. Кто специалист, подскажите, чем отличается?
> Выглядит как можно заменить на socket activation unit [в системд] над sshd-session,
> такая же минимальная функциональность. Кто специалист, подскажите, чем отличается?В опенбсде его нету - так что нате вам с лопаты вон те чудеса вместо этого.