Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз OpenSSH 9.8 с отключением алгоритма DSA и дополнительными механизмами защиты"	+/–
Сообщение от opennews (??), 01-Июл-24, 18:34
Опубликован релиз OpenSSH 9.8, открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP. Помимо устранения отдельно анонсированной критической уязвимости (CVE-2024-6387), позволяющей добиться удалённого выполнения кода с правами root на стадии до прохождения аутентификации, в новой версии исправлена ещё одна менее опасная уязвимость и предложено несколько существенных изменений, нацеленных на повышение безопасности... Подробнее: https://www.opennet.me/opennews/art.shtml?num=61473
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от Аноним (2), 01-Июл-24, 19:44	–1 +/–
И как таперь к старым linux'ам подключаться?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #4, #6, #7, #16, #32

3. Сообщение от Аноним (3), 01-Июл-24, 20:05	+1 +/–
Я, видимо, пропустил, а где пишут, что старые линуксы не будут работать? И что подразумевается под старостью?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

4. Сообщение от hshhhhh (ok), 01-Июл-24, 20:39	+1 +/–
даже к старым линуксам могут подключаться одновременно несколько человек. не жадничайте!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от Аноним (6), 01-Июл-24, 20:54	+/–
По telnet
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

7. Сообщение от Омнонном (?), 02-Июл-24, 01:08	+/–
А как сейчас подключаетесь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

8. Сообщение от Алкоголизм (?), 02-Июл-24, 03:51	+1 +/–
А зачем в принципе передавать именно нажатия при авторизации? Разве не проще собрать строку пароля на стороне клиента и попросту отправить её целиком? Либо, раз уж такая особенность протокола и парольной авторизации, то опять же набирать в буфер и передавать пачкой все нажатия, как какой-нибудь парольный менеждер. Разве остались ситуации, где требуется такой контроль ввода? Даже если подключить OTP, то это всё равно отправка другой такой же строки в большинстве случаев.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #53

10. Сообщение от Аноним (11), 02-Июл-24, 06:42	–1 +/–
А чего в эту тему не написали ссылку про связи опенбзд с ФБР? https://www.opennet.me/opennews/art.shtml?num=28998
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52

11. Сообщение от Аноним (11), 02-Июл-24, 06:47	+1 +/–
Потому что помимо ввода пароля существует обычная работа с консолью. А там удобнее чтобы работало как с обычным терминалом чем присылался текст и не известно как целевая машина будет работать с этим текстом. А тут если сказали ентер значит ентер, а не текст "нажат ентер". Но злые языки конечно знают что первичной целью был конечно же фингерпринтинг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #12

12. Сообщение от Ананим.orig (?), 02-Июл-24, 08:01	+/–
Ввод пароля происходит явно ДО открытия сессии, т.е. это уж точно не "обычная" работа с консолью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #13

13. Сообщение от ананим.orig (?), 02-Июл-24, 08:05	+2 +/–
И это не говоря о том, что все время думал что по сети летит хэш, а не сам пароль
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #14, #22

14. Сообщение от anonistrambler.ru (?), 02-Июл-24, 09:39	–2 +/–
Зачем хэш, это же закрытыи канал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #20

16. Сообщение от Соль земли (?), 02-Июл-24, 09:59	–1 +/–
Используя SHA-1, потому что других алгосов там нет, и старые версии не отличают шифрование ключа от алгоса подписи ключа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

17. Сообщение от Соль земли (?), 02-Июл-24, 10:09	+/–
Вынести бы ещё весь функционал в библиотеку, чтобы отпала необходимость в libssh/libssh2.
Ответить | Правка | Наверх | Cообщить модератору

20. Сообщение от ананим.orig (?), 02-Июл-24, 12:50	+/–
А зачем слать пароль, если сравнивать все равно будет с хэшем из shadow/..? Плюс это практика проверенная десятилетиями
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #21

21. Сообщение от ананим.orig (?), 02-Июл-24, 13:27	+/–
моя неправда: согласно 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ми) т.е. никакого «передавать именно нажатия при авторизации» не происходит — с чего ветка обсуждения и началась
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

22. Сообщение от _oleg_ (ok), 02-Июл-24, 13:28	+/–
Какой хэш? В зависимости от настроек pam на принимающей стороне может быть различный способ проверки пароля. /etc/shadow, ldap, свой велосипед и т.д.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #31

23. Сообщение от _oleg_ (ok), 02-Июл-24, 13:30	+1 +/–
Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании dsa, но убирать совсем - идиоты.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #44, #49, #50

24. Сообщение от Аноним (24), 02-Июл-24, 14:23	+/–
>Данные о нажатиях позволяют снимать биометрию пользователя.
Ответить | Правка | Наверх | Cообщить модератору

25. Сообщение от Аноним (-), 02-Июл-24, 15:46	+1 +/–
> Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со > своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании > dsa, но убирать совсем - идиоты. Так подключайся к старым коммутаторм старой версией либы. Они же не удалили предыдущие версии. А то тебе послушать - сидели бы до сих пор на первопне
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #26

26. Сообщение от _oleg_ (ok), 02-Июл-24, 17:03	+/–
>> Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со >> своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании >> dsa, но убирать совсем - идиоты. > Так подключайся к старым коммутаторм старой версией либы. > Они же не удалили предыдущие версии. > А то тебе послушать - сидели бы до сих пор на первопне Да ты ж моё золото. А где взять эту старую версию на новом дистре?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #27, #28, #30

27. Сообщение от Аноним (27), 02-Июл-24, 20:48	+/–
./configure make
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #34

28. Сообщение от Роман (??), 02-Июл-24, 21:19	+1 +/–
у системного администратора
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

29. Сообщение от Роман (??), 02-Июл-24, 21:21	–1 +/–
> Таким образом исполняемый файл sshd теперь содержит минимальную функциональность, необходимую для приёма нового сетевого соединения и запуска sshd-session для обработки сеанса. Выглядит как можно заменить на socket activation unit [в системд] над sshd-session, такая же минимальная функциональность. Кто специалист, подскажите, чем отличается?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #33

30. Сообщение от Аноним (-), 02-Июл-24, 21:32	+/–
> Да ты ж моё золото. А где взять эту старую версию на новом дистре? Возьми старый дистр. Заодно как раз разломают и тебя и коммутатор чтобы 2 раза не вставать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #36

31. Сообщение от ананим.orig (?), 03-Июл-24, 05:27	–1 +/–
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. Но  это не имеет отношения к тому что обсуждали, потому что все равно идет одним пакетом, а не пакет на каждое нажатие клавиши
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #37

32. Сообщение от Аноним (-), 03-Июл-24, 06:00	+/–
> И как таперь к старым linux'ам подключаться? Используя такой же старый linux :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

33. Сообщение от Аноним (-), 03-Июл-24, 06:03	+/–
> Выглядит как можно заменить на socket activation unit [в системд] над sshd-session, > такая же минимальная функциональность. Кто специалист, подскажите, чем отличается? В опенбсде его нету - так что нате вам с лопаты вон те чудеса вместо этого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

34. Сообщение от _oleg_ (ok), 03-Июл-24, 11:07	+1 +/–
> ./configure > make Ну я почему-то другого и не ожидал. Спасибо, не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #38

36. Сообщение от _oleg_ (ok), 03-Июл-24, 11:13	+/–
> Возьми старый дистр. Заодно как раз разломают и тебя и коммутатор чтобы > 2 раза не вставать. Какой старый? Куда я тебе его поставлю? Как на новые тогда ходить коммутаторы? Как их сломают через ssh, когда управление через отдельный vlan?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #45

37. Сообщение от _oleg_ (ok), 03-Июл-24, 11:48	+/–
> 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-клиентом этого нет, то всё что ли? Финита ля комедия. Зайти не сможем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #40

38. Сообщение от Аноним (27), 03-Июл-24, 13:00	+/–
Ну, я, помню, какое-то время поддерживал ppa для openssl+alpn+nginx - пока не подошел EOL для дистрибутивов, где это было актуально. Можете точно так же поддерживать пакеты для своего любимого дистрибутива. А если по простому, то не вижу проблем, если make install в какой-нибудь /opt.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #39

39. Сообщение от _oleg_ (ok), 03-Июл-24, 13:23	+1 +/–
> Ну, я, помню, какое-то время поддерживал ppa для openssl+alpn+nginx - пока не > подошел EOL для дистрибутивов, где это было актуально. Можете точно так > же поддерживать пакеты для своего любимого дистрибутива. > А если по простому, то не вижу проблем, если make install в > какой-нибудь /opt. Я уже понял, что не видишь. А они есть, между тем. Буквально через пару новых версий gcc/glibc/anylib старые проекты перестают собираться и их приходится править самому и это не всегда тривиально. У меня достаточно плясок с ./configure && make install на разных машинах по различным причинам на регулярной основе и так. Ещё +1 к этому списку никакого желания получать нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

40. Сообщение от ананим.orig (?), 03-Июл-24, 16:53	–1 +/–
разумеется вы можете использовать все что угодно, хоть свой 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 придумали не просто так. И вообще, о чем вы спорите то? > Речь идёт про передачу внутри защищённого канала во время аутентификации да, если вы так настроите свою систему - свободу творчества никто не отменял
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #41

41. Сообщение от _oleg_ (ok), 03-Июл-24, 17:27	+/–
> разумеется вы можете использовать все что угодно, хоть свой pam-модуль написать > но чтобы это работало именно с ssh, нужно чтобы он поддерживал передачу > именно пароля Он это давно поддерживает :-). Вряд ли найдётся много современных установок sshd без UsePAM yes в конфиге. Это просто не удобно. Про передачу пароля - ну об этом, вроде, и речь изначально. Странно было бы обсуждать случай с передачей пароля без активации аутентификации по паролю на стороне sshd, не так ли? > не либа, а тот, кто это всё настраивал :D В смысле не либа? А что организует проверку пользователя/пароля на стороне sshd? Различные pam-модули - .so-файлы. Плагины, модули - пофигу как назвать. Это либа, которая связывается налету с программой. > И вообще, о чем вы спорите то? О том, что пароль передаётся в чистом виде и уже на стороне sshd проверяется pam'ом по выбранной схеме. Вот о чём. И помоему это очевидно настолько, что не понятно о чём тут спорить. sshd понятия не имеет какая схема хранения паролей и не должен. В этом смысл pam. В ответ на: "И это не говоря о том, что все время думал что по сети летит хэш, а не сам пароль" и "А зачем слать пароль, если сравнивать все равно будет с хэшем из shadow/..?"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #42

42. Сообщение от ананим.orig (?), 04-Июл-24, 01:26	+/–
> Про передачу пароля - ну об этом, вроде, и речь изначально. нет. про передачу нажатия клавиш остальное - переливание из пустого в порожнее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #43

43. Сообщение от _oleg_ (ok), 04-Июл-24, 14:01	+/–
>> Про передачу пароля - ну об этом, вроде, и речь изначально. > нет. про передачу нажатия клавиш Значит показалось и это: "А зачем слать пароль, если сравнивать все равно будет с хэшем из shadow/..?" кто-то другой писал. > остальное - переливание из пустого в порожнее Это я уже заметил :-).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

44. Сообщение от r1 (?), 04-Июл-24, 19:06	+/–
Давить вендора чтоб обновил софт коммутатора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #47

45. Сообщение от Аноним (45), 05-Июл-24, 01:47	+/–
> Какой старый? Любой, по вкусу. > Куда я тебе его поставлю? Да куда угодно. На правах кэпа: на виртуалку! > Как на новые тогда ходить коммутаторы? Допустим из соседней виртуалки. А, это у эксперта мирового класса видимо нерешаемая задача? Ну тогда это вообще к вашему манагеру вопросы, зачем им такие овощи с таким скилом, не способные решить простейшую проблему. > Как их сломают через ssh, когда управление через отдельный vlan? Вы так железно уверены что у вас там в вашем уютном интранетикеводится? Судя по тупым вопросам это напрасная уверенность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #46

46. Сообщение от _oleg_ (ok), 05-Июл-24, 13:13	+/–
> Вы так железно уверены что у вас там в вашем уютном интранетикеводится? > Судя по тупым вопросам это напрасная уверенность. Судя по тому, что ты пишешь, тупой здесь только ты. Уверены, не уверены - что ты за чушь пишешь? Какие нахрен ВМ? Один ./configure && make предлагает, другой тьму ВМ городить, между которыми потом бегать, что бы найти ту, которая нужна для конкретного коммутатора. Что за бред? Вы, вообще, сами хоть раз что-то подобное делали с поддержкой этого самого в несколько лет хотя бы? Ты хоть понимаешь, что это гемор? А учитывая, что о том, что ты уже не можешь попасть на коммутатор ты узнаёшь когда на него надо срочно зайти, это вообще пипец. Ты понимаешь, что ты пишешь чушь? Ты серьёзно предполагаешь, что у провайдера больше проблем/дел нет, как играться с установкой и поддержкой разных версий ssh? Откуда вы такие вылупляетесь, вообще...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #48, #51, #54

47. Сообщение от _oleg_ (ok), 05-Июл-24, 13:18	+/–
> Давить вендора чтоб обновил софт коммутатора. Да это только в теории работает. Если баги в старых моделях фиксят, то уже спасибо. А какой-то там ssh, не влияющий на основную работу железки - забьют. Мы уже, в принципе, идём потихоньку к тому, что бы ходить на коммутаторы через telnet. Учитывая, что управлящий vlan огорожен от всего остального, это адекватный выход. Потому как ~/.ssh/config с исключениями для шифров по ip ширится от года к году.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

48. Сообщение от glad_valakas (-), 06-Июл-24, 09:55	+/–
> у провайдера больше проблем/дел нет, как играться с установкой и поддержкой разных версий ssh? наймите кого-нибудь кто умеет. 7000 руб/час норм оплата.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

49. Сообщение от mausglov (?), 06-Июл-24, 12:33	+1 +/–
Сделайте Docker контейнер со старым Линуксом для этой цели, делов-то...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

50. Сообщение от anonymous (??), 06-Июл-24, 15:25	+/–
Хакеры и солонки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

51. Сообщение от Sem (??), 07-Июл-24, 00:41	+/–
Оставь одну старую версию. Сделай тунель куда тебе надо, ходи через него. С ВМ, без ВМ. Докер себе сделай, если виртуалка для тебя - много ресурсов. Чего кричать то? Почему DSA убрали, в новости написали -  не хотят поддерживать старое днище.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

52. Сообщение от Аноним (52), 08-Июл-24, 23:47	+/–
2010? Вовремя откопали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

53. Сообщение от solardiz (ok), 10-Июл-24, 16:23	+/–
Речь о паролях, передаваемых внутри сессии, "например, при вводе паролей в su или sudo." А при парольной аутентификации в самом SSH, да, обычно (кроме редко используемого режима keyboard-interactive) пароль передается одной строкой. С этим тоже когда-то была уязвимость - можно было определить длину пароля, см. https://www.openwall.com/articles/SSH-Traffic-Analysis
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

54. Сообщение от Аноним (-), 10-Июл-24, 17:05	+/–
> Судя по тому, что ты пишешь, тупой здесь только ты. Уверены, не > уверены - что ты за чушь пишешь? Какие нахрен ВМ? Один > ./configure && make предлагает, другой тьму ВМ городить, А в чем проблема? У нормальных админов это streamlined, вкатить нужное дистро на энную виртуалку не займет много времени. Более того, с этой задачей накрайняк справится даже копеечный джун за несколько часов, даже если он не умеет ничего кроме next-next-next. После чего копии этой VM надолго решат ту траблу в масштабах хоть целой корпорации. А если у вас IT департамент в дауне настолько что не может такую простую проблему решить, очевидно это вопрос к менеджменту. На тему увольнения оттуда с треском всяких нерюхов которые не могут даже проблемы уровня нулевого джуна разрулить и вместо этого - пускают пузыри, да еще смеют такой уровень на публику казать. > бегать, что бы найти ту, которая нужна для конкретного коммутатора. Видимо этим, с пальмы, никто не сказал что можно запускать более 1 VM и бегать никуда не придется. > Что за бред? Вы, вообще, сами хоть раз что-то подобное делали с > поддержкой этого самого в несколько лет хотя бы? Прямо сейчас у меня запущено на вот этом воркстейшне около дюжины VM. И одна из причин это делать в том числе и изолирование разных рабочих и хобийных проектов друг от друга. Так что даже если что-то разнесут злые хакеры, урон ограничится только пострадавшим проектом. А остальное они вообще никогда не увидят. Да и атака будет скомпенсирована сносом VM или откатом снапшота. Сильно быстрее чем то что вы там могли изобразить в таких случаях. > Ты хоть понимаешь, что это гемор? Я понимаю что есть те кто не умеет в современный менеджмент инфраструктуры и эффективные подходы. Виртуалку под внутренние нужды можно даже не апдейтить особо и проч, только слушающие сервисы придушить. Хуже чем DSA и SSH лохматой версии все равно не станет, а в самом пиковом случае урон ограничен этой VM и тем что с нее менеджилось. А не вообще всем, от и до. > А учитывая, что о том, что ты уже не можешь попасть на коммутатор ты узнаёшь > когда на него надо срочно зайти, это вообще пипец. Ты понимаешь, что ты пишешь чушь? Я понимаю что у вас вашей чудной инсталяции з@дница с менеджментом и инфраструктурой, если все работает вот так. > Ты серьёзно предполагаешь, что у провайдера больше проблем/дел нет, как играться > с установкой и поддержкой разных версий ssh? Откуда вы такие вылупляетесь, вообще... А у вас еще и выбор, типа, будет? Кто же это вам за свой счет вашу некромансию то будет вечно оплачивать? Мир ради на вас не встанет на паузу. И вам как-то придется адаптироваться к изменчивости оного. Если вы не можете - чтож, то что не может адаптироваться к изменениям, вымирает. Так было миллиарды лет. Так есть. Так будет. Возможно, вы просто ошибка эволюции. Но этот мир жесток. Никаких скидок. Не можете адаптироваться - гудбай, динос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #55, #56

55. Сообщение от _oleg_ (ok), 10-Июл-24, 17:19	+/–
>> бегать, что бы найти ту, которая нужна для конкретного коммутатора. > Видимо этим, с пальмы, никто не сказал что можно запускать более 1 > VM и бегать никуда не придется. Ох... Даже не знаю смеяться или плакать. Я об этом и писал, что бегать между ВМ или контейнерами это гемор, когда нужно быстро попасть на железку. Что ж вы такие буквальные-то все... Я уже писал, что узнаешь ты о том, что не можешь попасть на какую-то железку как раз в тот момент, когда на неё нужно сейчас же зайти и некогда устраивать пляски с make и новой ВМ/контейнером. Но тут понабежали админы localhost'а, которые никогда не поддерживали подобную инфраструктуру с костылями годами и не знают что это такое, и начали меня смешить какими-то очевидными вещами. Вроде, "надо ./configure && make" или "да просто ВМ поставь". Пипец. >> Что за бред? Вы, вообще, сами хоть раз что-то подобное делали с >> поддержкой этого самого в несколько лет хотя бы? > Прямо сейчас у меня запущено на вот этом воркстейшне около дюжины VM. > И одна из причин это делать в том числе и изолирование > разных рабочих и хобийных проектов друг от друга. Так что даже > если что-то разнесут злые хакеры, урон ограничится только пострадавшим проектом. А > остальное они вообще никогда не увидят. Да и атака будет скомпенсирована > сносом VM или откатом снапшота. О, господи...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

56. Сообщение от _oleg_ (ok), 10-Июл-24, 17:26	+/–
> А у вас еще и выбор, типа, будет? Кто же это вам > за свой счет вашу некромансию то будет вечно оплачивать? Мир ради > на вас не встанет на паузу. И вам как-то придется адаптироваться > к изменчивости оного. Если вы не можете - чтож, то что > не может адаптироваться к изменениям, вымирает. Так было миллиарды лет. Так > есть. Так будет. Возможно, вы просто ошибка эволюции. Но этот мир > жесток. Никаких скидок. Не можете адаптироваться - гудбай, динос. Вот тебе это писать-то не лень было? Ты так и не понял о чём речь даже. Ты понимаешь хоть, что тут как бы речь про ответственность? ssh уже давно считается неким стандартом для входа на всякие железки. И он там нихера не обновляется как это себе могут представлять разрабы openssh. И хорошо бы у владельца такой железки иметь возможность на неё попасть и через 5 и через 10 лет. И поэтому, если авторам openssh моча в голову ударила, что что-то не безопасно, то стоит просто об этом написать при попытке соединиться с вопросом "Proceed (y/N)", а не лишать владельцев железки возможности на неё зайти. Это уже чуть больше, чем вопрос безопасности. Ты понимаешь это?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема