|
2.3, Аноним (3), 20:05, 01/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Я, видимо, пропустил, а где пишут, что старые линуксы не будут работать? И что подразумевается под старостью?
| |
2.4, hshhhhh (ok), 20:39, 01/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
даже к старым линуксам могут подключаться одновременно несколько человек. не жадничайте!
| |
2.16, Соль земли (?), 09:59, 02/07/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Используя SHA-1, потому что других алгосов там нет, и старые версии не отличают шифрование ключа от алгоса подписи ключа.
| |
2.32, Аноним (-), 06:00, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
> И как таперь к старым linux'ам подключаться?
Используя такой же старый linux :)
| |
|
1.8, Алкоголизм (?), 03:51, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А зачем в принципе передавать именно нажатия при авторизации? Разве не проще собрать строку пароля на стороне клиента и попросту отправить её целиком? Либо, раз уж такая особенность протокола и парольной авторизации, то опять же набирать в буфер и передавать пачкой все нажатия, как какой-нибудь парольный менеждер. Разве остались ситуации, где требуется такой контроль ввода? Даже если подключить OTP, то это всё равно отправка другой такой же строки в большинстве случаев.
| |
|
2.11, Аноним (11), 06:47, 02/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Потому что помимо ввода пароля существует обычная работа с консолью. А там удобнее чтобы работало как с обычным терминалом чем присылался текст и не известно как целевая машина будет работать с этим текстом. А тут если сказали ентер значит ентер, а не текст "нажат ентер". Но злые языки конечно знают что первичной целью был конечно же фингерпринтинг.
| |
|
3.12, Ананим.orig (?), 08:01, 02/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ввод пароля происходит явно ДО открытия сессии, т.е. это уж точно не "обычная" работа с консолью.
| |
|
4.13, ананим.orig (?), 08:05, 02/07/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
И это не говоря о том, что все время думал что по сети летит хэш, а не сам пароль
| |
|
|
6.20, ананим.orig (?), 12:50, 02/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
А зачем слать пароль, если сравнивать все равно будет с хэшем из shadow/..?
Плюс это практика проверенная десятилетиями
| |
|
7.21, ананим.orig (?), 13:27, 02/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
моя неправда:
согласно 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ми)
т.е. никакого «передавать именно нажатия при авторизации» не происходит — с чего ветка обсуждения и началась
| |
|
|
5.22, _oleg_ (ok), 13:28, 02/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Какой хэш? В зависимости от настроек pam на принимающей стороне может быть различный способ проверки пароля. /etc/shadow, ldap, свой велосипед и т.д.
| |
|
6.31, ананим.orig (?), 05:27, 03/07/2024 [^] [^^] [^^^] [ответить]
| –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.
Но это не имеет отношения к тому что обсуждали, потому что все равно идет одним пакетом, а не пакет на каждое нажатие клавиши
| |
|
7.37, _oleg_ (ok), 11:48, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
> 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-клиентом этого нет, то всё что ли? Финита ля комедия. Зайти не сможем.
| |
|
|
9.41, _oleg_ (ok), 17:27, 03/07/2024 [^] [^^] [^^^] [ответить] | +/– | Он это давно поддерживает - Вряд ли найдётся много современных установок sshd... текст свёрнут, показать | |
|
|
|
|
|
|
|
2.53, solardiz (ok), 16:23, 10/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Речь о паролях, передаваемых внутри сессии, "например, при вводе паролей в su или sudo." А при парольной аутентификации в самом SSH, да, обычно (кроме редко используемого режима keyboard-interactive) пароль передается одной строкой. С этим тоже когда-то была уязвимость - можно было определить длину пароля, см. https://www.openwall.com/articles/SSH-Traffic-Analysis
| |
|
1.17, Соль земли (?), 10:09, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вынести бы ещё весь функционал в библиотеку, чтобы отпала необходимость в libssh/libssh2.
| |
1.23, _oleg_ (ok), 13:30, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании dsa, но убирать совсем - идиоты.
| |
|
2.25, Аноним (-), 15:46, 02/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со
> своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании
> dsa, но убирать совсем - идиоты.
Так подключайся к старым коммутаторм старой версией либы.
Они же не удалили предыдущие версии.
А то тебе послушать - сидели бы до сих пор на первопне
| |
|
3.26, _oleg_ (ok), 17:03, 02/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
>> Вот красавцы. Как к старым коммутаторам подключаться-то? Как они задолбали уже со
>> своей псевдозаботой о моей безопасности. Ну выводите вы предупреждение при использовании
>> dsa, но убирать совсем - идиоты.
> Так подключайся к старым коммутаторм старой версией либы.
> Они же не удалили предыдущие версии.
> А то тебе послушать - сидели бы до сих пор на первопне
Да ты ж моё золото. А где взять эту старую версию на новом дистре?
| |
|
|
5.34, _oleg_ (ok), 11:07, 03/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> ./configure
> make
Ну я почему-то другого и не ожидал. Спасибо, не надо.
| |
|
6.38, Аноним (27), 13:00, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ну, я, помню, какое-то время поддерживал ppa для openssl+alpn+nginx - пока не подошел EOL для дистрибутивов, где это было актуально. Можете точно так же поддерживать пакеты для своего любимого дистрибутива.
А если по простому, то не вижу проблем, если make install в какой-нибудь /opt.
| |
|
7.39, _oleg_ (ok), 13:23, 03/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Ну, я, помню, какое-то время поддерживал ppa для openssl+alpn+nginx - пока не
> подошел EOL для дистрибутивов, где это было актуально. Можете точно так
> же поддерживать пакеты для своего любимого дистрибутива.
> А если по простому, то не вижу проблем, если make install в
> какой-нибудь /opt.
Я уже понял, что не видишь. А они есть, между тем. Буквально через пару новых версий gcc/glibc/anylib старые проекты перестают собираться и их приходится править самому и это не всегда тривиально. У меня достаточно плясок с ./configure && make install на разных машинах по различным причинам на регулярной основе и так. Ещё +1 к этому списку никакого желания получать нет.
| |
|
|
|
4.30, Аноним (-), 21:32, 02/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Да ты ж моё золото. А где взять эту старую версию на новом дистре?
Возьми старый дистр. Заодно как раз разломают и тебя и коммутатор чтобы 2 раза не вставать.
| |
|
5.36, _oleg_ (ok), 11:13, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Возьми старый дистр. Заодно как раз разломают и тебя и коммутатор чтобы
> 2 раза не вставать.
Какой старый? Куда я тебе его поставлю? Как на новые тогда ходить коммутаторы? Как их сломают через ssh, когда управление через отдельный vlan?
| |
|
6.45, Аноним (45), 01:47, 05/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Какой старый?
Любой, по вкусу.
> Куда я тебе его поставлю?
Да куда угодно. На правах кэпа: на виртуалку!
> Как на новые тогда ходить коммутаторы?
Допустим из соседней виртуалки. А, это у эксперта мирового класса видимо нерешаемая задача? Ну тогда это вообще к вашему манагеру вопросы, зачем им такие овощи с таким скилом, не способные решить простейшую проблему.
> Как их сломают через ssh, когда управление через отдельный vlan?
Вы так железно уверены что у вас там в вашем уютном интранетикеводится? Судя по тупым вопросам это напрасная уверенность.
| |
|
7.46, _oleg_ (ok), 13:13, 05/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Вы так железно уверены что у вас там в вашем уютном интранетикеводится?
> Судя по тупым вопросам это напрасная уверенность.
Судя по тому, что ты пишешь, тупой здесь только ты. Уверены, не уверены - что ты за чушь пишешь? Какие нахрен ВМ? Один ./configure && make предлагает, другой тьму ВМ городить, между которыми потом бегать, что бы найти ту, которая нужна для конкретного коммутатора. Что за бред? Вы, вообще, сами хоть раз что-то подобное делали с поддержкой этого самого в несколько лет хотя бы? Ты хоть понимаешь, что это гемор? А учитывая, что о том, что ты уже не можешь попасть на коммутатор ты узнаёшь когда на него надо срочно зайти, это вообще пипец. Ты понимаешь, что ты пишешь чушь? Ты серьёзно предполагаешь, что у провайдера больше проблем/дел нет, как играться с установкой и поддержкой разных версий ssh? Откуда вы такие вылупляетесь, вообще...
| |
|
8.51, Sem (??), 00:41, 07/07/2024 [^] [^^] [^^^] [ответить] | +/– | Оставь одну старую версию Сделай тунель куда тебе надо, ходи через него С ВМ, ... текст свёрнут, показать | |
8.54, Аноним (-), 17:05, 10/07/2024 [^] [^^] [^^^] [ответить] | +/– | А в чем проблема У нормальных админов это streamlined, вкатить нужное дистро на... большой текст свёрнут, показать | |
|
9.56, _oleg_ (ok), 17:26, 10/07/2024 [^] [^^] [^^^] [ответить] | +/– | Вот тебе это писать-то не лень было Ты так и не понял о чём речь даже Ты поним... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
3.47, _oleg_ (ok), 13:18, 05/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Давить вендора чтоб обновил софт коммутатора.
Да это только в теории работает. Если баги в старых моделях фиксят, то уже спасибо. А какой-то там ssh, не влияющий на основную работу железки - забьют. Мы уже, в принципе, идём потихоньку к тому, что бы ходить на коммутаторы через telnet. Учитывая, что управлящий vlan огорожен от всего остального, это адекватный выход. Потому как ~/.ssh/config с исключениями для шифров по ip ширится от года к году.
| |
|
2.49, mausglov (?), 12:33, 06/07/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Сделайте Docker контейнер со старым Линуксом для этой цели, делов-то...
| |
|
1.29, Роман (??), 21:21, 02/07/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> Таким образом исполняемый файл sshd теперь содержит минимальную функциональность, необходимую для приёма нового сетевого соединения и запуска sshd-session для обработки сеанса.
Выглядит как можно заменить на socket activation unit [в системд] над sshd-session, такая же минимальная функциональность. Кто специалист, подскажите, чем отличается?
| |
|
2.33, Аноним (-), 06:03, 03/07/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Выглядит как можно заменить на socket activation unit [в системд] над sshd-session,
> такая же минимальная функциональность. Кто специалист, подскажите, чем отличается?
В опенбсде его нету - так что нате вам с лопаты вон те чудеса вместо этого.
| |
|
|