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

"Google опубликовал HIBA, надстройку над OpenSSH для авторизации на основе сертификатов"	+/–
Сообщение от opennews (ok), 21-Сен-21, 12:53
Компания Google опубликовала исходные тексты проекта HIBA (Host Identity Based Authorization), предлагающего реализацию дополнительного механизма авторизации для организации доступа пользователей по SSH в привязке к хостам (проверки, разрешён или нет доступ к конкретному ресурсу при аутентификации по открытым ключам).  Интеграция с OpenSSH обеспечивается через указание обработчика HIBA в директиве AuthorizedPrincipalsCommand в /etc/ssh/sshd_config. Код проекта написан на языке Си и распространяется под лицензией BSD... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55841
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Arcade (ok), 21-Сен-21, 12:53	+10 +/–
Не понял чо нового по сравнению с SSH CA: вроде всё то же самое.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #11

2. Сообщение от нах.. (?), 21-Сен-21, 12:55	+/–
Яссно, еще один зонд. Буду знать врага в лицо и выпиливать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #13, #43

4. Сообщение от scor (ok), 21-Сен-21, 13:01	+4 +/–
> все проверки целиком на стороне целевого хоста ... без обращения к внешним службам ага. Пока не понадобится отозвать какой-то сертификат. Тут и начнётся "здравствуй x509". Ну или CRL-ки переодически раскладывать на каждый хост. Тогда не понятно, чем это отличается от сейчас.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #23

5. Сообщение от Crazy Alex (ok), 21-Сен-21, 13:08	+2 +/–
От сейчас - очень понятно, чем. Ты забил в сертификат "годен для подключения к хостам a, b, c" - и так оно и отработает. Или прибил признак какой-то - и нужным хостам задаёшь - пускать по сертификатам с данным значением данного признака. А отзыв - не страшнее, чем сейчас. Сейчас надо по всем хостам из всех authorized_keys выкинуть соответствующие записи, автоматическиое обновление их CRL ничем не хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #8

6. Сообщение от Crazy Alex (ok), 21-Сен-21, 13:09	+9 +/–
Ни хрена тебе не ясно. Что и откуда ты выпиливать собрался, если это отдельная приблуда, разворачиваемая владельцем инфраструктуры там, где ему надо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #10

7. Сообщение от Crazy Alex (ok), 21-Сен-21, 13:12	+2 +/–
Я тмк понимаю, тут проще напихать какие-то произвольные признаки и по ним матчить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

8. Сообщение от scor (ok), 21-Сен-21, 13:14	+1 +/–
> Ты забил в сертификат "годен для подключения к хостам a, b, c" - и так оно и > отработает. Или просто не положил паблик пользователя на хост... > А отзыв - не страшнее, чем сейчас. Сейчас надо по всем хостам > из всех authorized_keys выкинуть соответствующие записи, автоматическиое обновление > их CRL ничем не хуже. Т.е. нужно точно также ходить по всем хостам и что-то там править? Ну т.е. все теже проблемы, что и сейчас, только в новой обёртке и файлы по другому называются. Окай.:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #14, #27

10. Сообщение от Анто Нимно (?), 21-Сен-21, 13:15	–3 +/–
Это на бабло развод в будущем. Есть конторы, торгующие сертами и пропри-прошивки с сертами... Профит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #22, #31

11. Сообщение от Анто Нимно (?), 21-Сен-21, 13:17	+2 +/–
Ничего нового. CA, приносящий доход, уже существует. Оставалось просто соединить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

13. Сообщение от Аноним (13), 21-Сен-21, 13:19	+2 +/–
Будешь выпиливать отовсюду OpenSSH и ставить Telnet? Я слышал что где-то глубоко в недрах сиски практикуют так называемый "Telnet over SSL", отпишись когда попробуешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #15, #16

14. Сообщение от Аноним (14), 21-Сен-21, 13:56	+1 +/–
Глобальная разница в том, что оаньше ты обходил все хосты, чтобы добавить и чтобы удалить. Тут можно обходить хосты только в случае незапланированного принудительного удаления. Плюс, скорее всего, как в OAuth2, подписи CA сделают короткоживущими, типа, пяти минут. В случае компрометации ключа, его блокируют на CA и через пять минут, когда на нем протухнет подпись, никто не сможет ее восстановить и автоматически ключ станет недействителен на всех хостах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

15. Сообщение от нах... (?), 21-Сен-21, 13:57	–3 +/–
выпилил. телнет работает отлично
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #18

16. Сообщение от aa (?), 21-Сен-21, 13:57	+1 +/–
как будто для SSL под телнетом не нужны сертификаты/СА и всё такое
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #53

18. Сообщение от PnD (??), 21-Сен-21, 14:20	+1 +/–
Стесняюсь спросить (но спрошу). А telnetd запускаете из-под православного inetd (xinetd)? Или обернув б-мерзким systemd [Socket]? Так-то да. Чего ж не обойтись. Даже в ssl можно обернуть. Правда, есть нюанс: stderr так не получить в отдельном fd. Ой, а может он у вас на железках вроде cs2950? Тогда, конечно…
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

21. Сообщение от gogo (?), 21-Сен-21, 15:18	+/–
Что-то я не пойму, если таким сертом завладел злоумышленник и ты об этом знаешь, то что делать? Из описания я не вижу, как можно заблокировать конкретный сертификат. Разве что только удалить ключи удостоверяющего центра.
Ответить | Правка | Наверх | Cообщить модератору

22. Сообщение от Аноним (22), 21-Сен-21, 15:42	+/–
У ALPHABET не кислые дольки почти в каждом CA. Почему бы гуглу не возглавить openssh?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

23. Сообщение от Аноним (22), 21-Сен-21, 15:50	+1 +/–
>> Тогда не понятно, чем это отличается от сейчас. Сейчас о вас заботы нету. Будет. Сначала сделаем надстройку Потом её протащим как стандарт де-факто Надстройка становится неотъемлемой частью проекта Рулим проектом и его аудиторией Сдохнет всё - не жалко, вложения минимальны, чужой проект сдох Или получим прибыль, просто здорово А то как же пользователи и без заботы? Сейчас про OpenSSH, но для гугла это один из стандартных подходов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #54

25. Сообщение от Аноним (25), 21-Сен-21, 16:21	+1 +/–
Какой-то сраный велосипед. 1) отзыв сертов (об этом уже писали на форуме) 2) что делать, если захотим поменять доступ конкретному серту? Генерить новый серт ? Старый отзывать ? И да, походу отзыв нужно делать на ВСЕХ хостах отдельно Прикрутить LDAP к sshd в гугле не осилили, создают ведосипеды
Ответить | Правка | Наверх | Cообщить модератору

26. Сообщение от Совсем не аноним (?), 21-Сен-21, 16:28	+/–
Зачем, когда есть FreeIPA или LDAP?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29

27. Сообщение от OpenEcho (?), 21-Сен-21, 16:31	+1 +/–
Все наоборот. Хосты бегают за обновой. Хосты переодически шлют GraphQL запрос на "базу" со своим состоянием и если что есть к обнове, пикапают (и CRL в том числе). Если на базе нет коннектов с какого-то хоста то это аларм, т.е мониторинг & контрол all-in-one
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #34

28. Сообщение от Аноним (29), 21-Сен-21, 16:38	+/–
Годнейшая штука, реально не хватает такой. Надеюсь её как можно скорее интегрируют сразу в OpenSSH.
Ответить | Правка | Наверх | Cообщить модератору

29. Сообщение от Аноним (29), 21-Сен-21, 16:42	–1 +/–
Затем, чтобы не надо было иметь целый отдельный сервис, который надо обслуживать, следить за безопасность и доступностью, выписывать и распространять сертификаты. Позволяет пропустить бессмысленные телодвижения и проверить валидность пользователя прямо на хосте, без использования внешних ресурсов. Админам высоконагруженных локалхостов не понять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #32

30. Сообщение от anonymous (??), 21-Сен-21, 16:42	+1 +/–
openssh поддерживает x509. Нахрена тут нужен этот велосипед?
Ответить | Правка | Наверх | Cообщить модератору

31. Сообщение от Тфьу (?), 21-Сен-21, 17:07	+/–
никто не заставляет покупать платный сертификат, можно использовать свой СА
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #44, #45

32. Сообщение от Тфьу (?), 21-Сен-21, 17:09	+/–
но нужно следить за своим СА и за ЦРЛками, следить, чтобы они обновлялись своевременно на всех хостах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #39

34. Сообщение от scor (ok), 21-Сен-21, 17:50	+2 +/–
> Все наоборот. Хосты бегают за обновой. > Хосты переодически шлют GraphQL запрос на "базу" со своим состоянием и если > что есть к обнове, пикапают (и CRL в том числе). Это всё только на бумаге работает. В реальной жизни всё печальней обычно. Что делать хосту, если он не смог обновить CRL? Не пускать никого пока не обновит? Или пускать основываясь на старой версии CRL? И любой из этих варинтов плох, к сожалению. > Если > на базе нет коннектов с какого-то хоста то это аларм, т.е > мониторинг & контрол all-in-one В каких-то масштабах это наверное даже работает и выглядит прикольно. Только всё вот это, на ровном месте требует создания и поддержания дополнительной инфраструктуры, которую нужно мейнтейнить, мониторить и на ноды которой тоже нужно как-то попадать. А в замен предлагается схема с дополнительной авторизацией, которая не понятно какие бонусы даёт и к тому же, в общем случае, не работает. Ну и, возвращаясь к старту треда. Это вовсе не выглядит как "все проверки целиком на стороне целевого хоста ... без обращения к внешним службам". То, что можно построить бессмысленных велосипедов любой сложности никто и не спорит, так-то.:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

35. Сообщение от Аноним (-), 21-Сен-21, 18:23	+1 +/–
> Код проекта написан на языке Си Переписать на руст, затем удалить и снова переписать. Возможно, тогда и станет безопасным. // b.
Ответить | Правка | Наверх | Cообщить модератору

36. Сообщение от Аноним (36), 21-Сен-21, 18:43	+/–
https://www.earth.li/~noodles/blog/2019/04/totp-auth.html А что насчет SSH 2FA TOTP, все уже несекурно?) Там либа от Гугла но она никак с ним не связана, никуда не стучит, просто генерирует числа на стороне сервера. На стороне клиента можно использовать любой 2фа софт или Yubikey.
Ответить | Правка | Наверх | Cообщить модератору

37. Сообщение от AnonymPatient (?), 21-Сен-21, 18:59	+/–
>>Проверка на стороне хоста инициируется через вызов обработчика hiba-chk, прописанного в директиве AuthorizedPrincipalsCommand. >>Данный обработчик декодирует интегрированные в сертификаты расширения и на их основе принимает решение о предоставлении или блокировании доступа. >>Правила доступа определяются централизованно на уровне удостоверяющего центра (CA) и интегрируются в сертификаты на этапе их генерации. Не озвучены пара фундументальных вещей: - где можно записаться в бенефициары CA ? - сколько сольдо будет стоить абонемент на 10-хостов ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #38

38. Сообщение от ibaca (?), 21-Сен-21, 19:20	+/–
Нисколько, вот пример: https://github.com/cloudtools/ssh-ca
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

39. Сообщение от Аноним (39), 21-Сен-21, 19:24	+1 +/–
А с LDAP не нужно что ли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

40. Сообщение от Андрей (??), 21-Сен-21, 20:14	+/–
Хиба цэ шо то новое?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41

41. Сообщение от Анончик (?), 21-Сен-21, 20:40	+/–
SSH CA в другой руке
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

43. Сообщение от Аноним (-), 21-Сен-21, 21:42	–2 +/–
Я вражескими поделками ваще не пользуюсь уже лет семь, чего и вам желаю. Вы будете улыбаться, слыша слово ... да и ваще все эти buzzwords. Вы же умны, так применяйте свой ум.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #46, #51, #56

44. Сообщение от Аноним (44), 21-Сен-21, 21:44	+/–
Не можно, а нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

45. Сообщение от кокпок (?), 21-Сен-21, 21:57	+/–
Варианта использовать НЕ свой CA в данном случае нету, он всегда будет свой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

46. Сообщение от кокпок (?), 21-Сен-21, 21:59	–1 +/–
А чем пользуетесь берестой и углем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

48. Сообщение от Атон (?), 21-Сен-21, 23:13	–1 +/–
> Правила доступа определяются централизованно на уровне удостоверяющего центра (CA) и интегрируются в сертификаты на этапе их генерации. владелец СА конечно гугл, будет брать деньги за каждый сертификат, гугл в любой момент может по своему желанию отозвать мой сертификат, или исключить из моего сертификата любой мой хост? годно!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49

49. Сообщение от Анончик (?), 22-Сен-21, 00:31	+/–
>владелец СА конечно гугл Да вас насильно тащат под крыло гугла ведь только гугл может быть CA. Других то CA нет больше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #60

50. Сообщение от Ivan_83 (ok), 22-Сен-21, 02:43	+1 +/–
Осталось дождатся новостей когда там найдут дыру и будут входит по мастер ключу везде.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52

51. Сообщение от Прохожий (??), 22-Сен-21, 08:03	+/–
Скрепы - наше всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

52. Сообщение от Аноним (36), 22-Сен-21, 09:40	–1 +/–
Как работают ключи ssh тяжело погуглить, прежде чем такой бред писать? Может еще найдут мастер пароль от всех ssh в мире? Мало ли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #59

53. Сообщение от Аноним (13), 22-Сен-21, 10:27	+/–
Так же как OPENSSH, но человек хочет быть другим, не таким как все.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

54. Сообщение от странадураков (?), 22-Сен-21, 12:44	+1 +/–
> Сначала сделаем надстройку > Потом её протащим как стандарт де-факто > Надстройка становится неотъемлемой частью проекта казалось бы, причём здесь всего-лишь новый нескучный инит, новый безопасный язык,.. новый....
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

55. Сообщение от 0x501D (?), 22-Сен-21, 16:09	+/–
Есть же PKIX-SSH
Ответить | Правка | Наверх | Cообщить модератору

56. Сообщение от Аноним (-), 22-Сен-21, 17:04	+1 +/–
Правильно! Гугл давно перешёл все рамки приличия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

57. Сообщение от Kenneth (?), 22-Сен-21, 17:23	+/–
нашаHIBA.
Ответить | Правка | Наверх | Cообщить модератору

58. Сообщение от Аноним (58), 22-Сен-21, 17:28	+/–
Больше зондов от гугла=больше уязвимостей в том что и так уязвимо.
Ответить | Правка | Наверх | Cообщить модератору

59. Сообщение от Атон (?), 22-Сен-21, 21:16	+/–
> Как работают ключи ssh тяжело погуглить, прежде чем такой бред писать? > Может еще найдут мастер пароль от всех ssh в мире? Мало ли. осталось понять что это старые ключи работали по другому, а _НОВЫЕ_ будут вот так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

60. Сообщение от Атон (?), 22-Сен-21, 21:24	+/–
>>владелец СА конечно гугл > Да вас насильно тащат под крыло гугла ведь только гугл может быть > CA. > Других то CA нет больше. название - не имеет значения. читай внимательно: СА выдает ПОЛЬЗОВАТЕЛЮ сертификат. пользователь с этим сертификатом коннектится к удаленному хосту. удаленный хост проверяет сертификат в СА выпустившем этот сертификат, и узнает какие права имеет этот пользователь на этом хосте. сколько ты готов платить гуглу (+ всем остальным СА, раз ты такой умный) чтобы они _НЕ_ выпускали сертификаты разрешающие подключатся к твоим серверам?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #62

61. Сообщение от anonymous (??), 23-Сен-21, 12:04	+/–
Чего-то люди совсем уже поехали. Google опубликовал разработку и за это они хейтят Google. Нет бы форкнуть и исправить то, что не нравится; либо вообще проигнорировать новость, если им эта разработка не нужна (ибо ведь никуда не форсится). Но ведь нет, надо фантазировать, что это завязка на Google-вые CA и прочие теории заговора.
Ответить | Правка | Наверх | Cообщить модератору

62. Сообщение от Аноним (62), 23-Сен-21, 22:09	+/–
> сколько ты готов платить гуглу (+ всем остальным СА, раз ты такой умный) чтобы они _НЕ_ выпускали сертификаты разрешающие подключатся к твоим серверам? Я лично нисколько, но как корпорация — тыщ 10 за SLA заплатил бы с порога. Правда, неясно куда деньги нести, сертификаты SSH не завязаны ни на какой публичный CA by design. Там даже опции такой нет, надо со своим CA приходить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #63

63. Сообщение от Атон (?), 24-Сен-21, 12:30	+/–
>> сколько ты готов платить гуглу (+ всем остальным СА, раз ты такой умный) чтобы они _НЕ_ выпускали сертификаты разрешающие подключатся к твоим серверам? > Я лично нисколько, но как корпорация — тыщ 10 за SLA заплатил > бы с порога. Правда, неясно куда деньги нести, вот в каждый СА и нести. по 10 тысяч каждую неделю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

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

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