Компания Google опубликовала исходные тексты проекта HIBA (Host Identity Based Authorization), предлагающего реализацию дополнительного механизма авторизации для организации доступа пользователей по SSH в привязке к хостам (проверки, разрешён или нет доступ к конкретному ресурсу при аутентификации по открытым ключам). Интеграция с OpenSSH обеспечивается через указание обработчика HIBA в директиве AuthorizedPrincipalsCommand в /etc/ssh/sshd_config. Код проекта написан на языке Си и распространяется под лицензией BSD...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=55841
Не понял чо нового по сравнению с SSH CA: вроде всё то же самое.
Я тмк понимаю, тут проще напихать какие-то произвольные признаки и по ним матчить
Ничего нового. CA, приносящий доход, уже существует. Оставалось просто соединить.
Яссно, еще один зонд. Буду знать врага в лицо и выпиливать.
Ни хрена тебе не ясно. Что и откуда ты выпиливать собрался, если это отдельная приблуда, разворачиваемая владельцем инфраструктуры там, где ему надо?
Это на бабло развод в будущем. Есть конторы, торгующие сертами и пропри-прошивки с сертами... Профит.
У ALPHABET не кислые дольки почти в каждом CA.
Почему бы гуглу не возглавить openssh?
никто не заставляет покупать платный сертификат, можно использовать свой СА
Не можно, а нужно.
Варианта использовать НЕ свой CA в данном случае нету, он всегда будет свой.
Будешь выпиливать отовсюду OpenSSH и ставить Telnet? Я слышал что где-то глубоко в недрах сиски практикуют так называемый "Telnet over SSL", отпишись когда попробуешь.
выпилил. телнет работает отлично
Стесняюсь спросить (но спрошу).
А telnetd запускаете из-под православного inetd (xinetd)? Или обернув б-мерзким systemd [Socket]?Так-то да. Чего ж не обойтись. Даже в ssl можно обернуть. Правда, есть нюанс: stderr так не получить в отдельном fd.
Ой, а может он у вас на железках вроде cs2950? Тогда, конечно…
как будто для SSL под телнетом не нужны сертификаты/СА и всё такое
Так же как OPENSSH, но человек хочет быть другим, не таким как все.
Я вражескими поделками ваще не пользуюсь уже лет семь, чего и вам желаю. Вы будете улыбаться, слыша слово ... да и ваще все эти buzzwords. Вы же умны, так применяйте свой ум.
А чем пользуетесь берестой и углем?
Скрепы - наше всё.
Правильно! Гугл давно перешёл все рамки приличия.
> все проверки целиком на стороне целевого хоста ... без обращения к внешним службамага. Пока не понадобится отозвать какой-то сертификат. Тут и начнётся "здравствуй x509". Ну или CRL-ки переодически раскладывать на каждый хост. Тогда не понятно, чем это отличается от сейчас.
От сейчас - очень понятно, чем. Ты забил в сертификат "годен для подключения к хостам a, b, c" - и так оно и отработает. Или прибил признак какой-то - и нужным хостам задаёшь - пускать по сертификатам с данным значением данного признака.А отзыв - не страшнее, чем сейчас. Сейчас надо по всем хостам из всех authorized_keys выкинуть соответствующие записи, автоматическиое обновление их CRL ничем не хуже.
> Ты забил в сертификат "годен для подключения к хостам a, b, c" - и так оно и
> отработает.Или просто не положил паблик пользователя на хост...
> А отзыв - не страшнее, чем сейчас. Сейчас надо по всем хостам
> из всех authorized_keys выкинуть соответствующие записи, автоматическиое обновление
> их CRL ничем не хуже.Т.е. нужно точно также ходить по всем хостам и что-то там править? Ну т.е. все теже проблемы, что и сейчас, только в новой обёртке и файлы по другому называются. Окай.:)
Глобальная разница в том, что оаньше ты обходил все хосты, чтобы добавить и чтобы удалить. Тут можно обходить хосты только в случае незапланированного принудительного удаления.
Плюс, скорее всего, как в OAuth2, подписи CA сделают короткоживущими, типа, пяти минут. В случае компрометации ключа, его блокируют на CA и через пять минут, когда на нем протухнет подпись, никто не сможет ее восстановить и автоматически ключ станет недействителен на всех хостах.
Все наоборот. Хосты бегают за обновой.
Хосты переодически шлют GraphQL запрос на "базу" со своим состоянием и если что есть к обнове, пикапают (и CRL в том числе). Если на базе нет коннектов с какого-то хоста то это аларм, т.е мониторинг & контрол all-in-one
> Все наоборот. Хосты бегают за обновой.
> Хосты переодически шлют GraphQL запрос на "базу" со своим состоянием и если
> что есть к обнове, пикапают (и CRL в том числе).Это всё только на бумаге работает. В реальной жизни всё печальней обычно. Что делать хосту, если он не смог обновить CRL? Не пускать никого пока не обновит? Или пускать основываясь на старой версии CRL? И любой из этих варинтов плох, к сожалению.
> Если
> на базе нет коннектов с какого-то хоста то это аларм, т.е
> мониторинг & контрол all-in-oneВ каких-то масштабах это наверное даже работает и выглядит прикольно. Только всё вот это, на ровном месте требует создания и поддержания дополнительной инфраструктуры, которую нужно мейнтейнить, мониторить и на ноды которой тоже нужно как-то попадать. А в замен предлагается схема с дополнительной авторизацией, которая не понятно какие бонусы даёт и к тому же, в общем случае, не работает.
Ну и, возвращаясь к старту треда. Это вовсе не выглядит как "все проверки целиком на стороне целевого хоста ... без обращения к внешним службам". То, что можно построить бессмысленных велосипедов любой сложности никто и не спорит, так-то.:)
>> Тогда не понятно, чем это отличается от сейчас.Сейчас о вас заботы нету. Будет.
Сначала сделаем надстройку
Потом её протащим как стандарт де-факто
Надстройка становится неотъемлемой частью проекта
Рулим проектом и его аудиторией
Сдохнет всё - не жалко, вложения минимальны, чужой проект сдох
Или получим прибыль, просто здоровоА то как же пользователи и без заботы?
Сейчас про OpenSSH, но для гугла это один из стандартных подходов
> Сначала сделаем надстройку
> Потом её протащим как стандарт де-факто
> Надстройка становится неотъемлемой частью проектаказалось бы, причём здесь всего-лишь новый нескучный инит, новый безопасный язык,.. новый....
Что-то я не пойму, если таким сертом завладел злоумышленник и ты об этом знаешь, то что делать?
Из описания я не вижу, как можно заблокировать конкретный сертификат. Разве что только удалить ключи удостоверяющего центра.
Какой-то сраный велосипед.
1) отзыв сертов (об этом уже писали на форуме)
2) что делать, если захотим поменять доступ конкретному серту? Генерить новый серт ? Старый отзывать ?И да, походу отзыв нужно делать на ВСЕХ хостах отдельно
Прикрутить LDAP к sshd в гугле не осилили, создают ведосипеды
Зачем, когда есть FreeIPA или LDAP?
Затем, чтобы не надо было иметь целый отдельный сервис, который надо обслуживать, следить за безопасность и доступностью, выписывать и распространять сертификаты. Позволяет пропустить бессмысленные телодвижения и проверить валидность пользователя прямо на хосте, без использования внешних ресурсов. Админам высоконагруженных локалхостов не понять.
но нужно следить за своим СА и за ЦРЛками, следить, чтобы они обновлялись своевременно на всех хостах.
А с LDAP не нужно что ли?
Годнейшая штука, реально не хватает такой. Надеюсь её как можно скорее интегрируют сразу в OpenSSH.
openssh поддерживает x509. Нахрена тут нужен этот велосипед?
> Код проекта написан на языке СиПереписать на руст, затем удалить и снова переписать. Возможно, тогда и станет безопасным.
// b.
https://www.earth.li/~noodles/blog/2019/04/totp-auth.htmlА что насчет SSH 2FA TOTP, все уже несекурно?)
Там либа от Гугла но она никак с ним не связана, никуда не стучит, просто генерирует числа на стороне сервера.
На стороне клиента можно использовать любой 2фа софт или Yubikey.
>>Проверка на стороне хоста инициируется через вызов обработчика hiba-chk, прописанного в директиве AuthorizedPrincipalsCommand.
>>Данный обработчик декодирует интегрированные в сертификаты расширения и на их основе принимает решение о предоставлении или блокировании доступа.
>>Правила доступа определяются централизованно на уровне удостоверяющего центра (CA) и интегрируются в сертификаты на этапе их генерации.Не озвучены пара фундументальных вещей:
- где можно записаться в бенефициары CA ?
- сколько сольдо будет стоить абонемент на 10-хостов ?
Нисколько, вот пример:
https://github.com/cloudtools/ssh-ca
Хиба цэ шо то новое?
SSH CA в другой руке
> Правила доступа определяются централизованно на уровне удостоверяющего центра (CA) и интегрируются в сертификаты на этапе их генерации.владелец СА конечно гугл, будет брать деньги за каждый сертификат, гугл в любой момент может по своему желанию отозвать мой сертификат, или исключить из моего сертификата любой мой хост?
годно!
>владелец СА конечно гуглДа вас насильно тащат под крыло гугла ведь только гугл может быть CA.
Других то CA нет больше.
>>владелец СА конечно гугл
> Да вас насильно тащат под крыло гугла ведь только гугл может быть
> CA.
> Других то CA нет больше.название - не имеет значения.
читай внимательно: СА выдает ПОЛЬЗОВАТЕЛЮ сертификат. пользователь с этим сертификатом коннектится к удаленному хосту. удаленный хост проверяет сертификат в СА выпустившем этот сертификат, и узнает какие права имеет этот пользователь на этом хосте.
сколько ты готов платить гуглу (+ всем остальным СА, раз ты такой умный) чтобы они _НЕ_ выпускали сертификаты разрешающие подключатся к твоим серверам?
> сколько ты готов платить гуглу (+ всем остальным СА, раз ты такой умный) чтобы они _НЕ_ выпускали сертификаты разрешающие подключатся к твоим серверам?Я лично нисколько, но как корпорация — тыщ 10 за SLA заплатил бы с порога. Правда, неясно куда деньги нести, сертификаты SSH не завязаны ни на какой публичный CA by design. Там даже опции такой нет, надо со своим CA приходить.
>> сколько ты готов платить гуглу (+ всем остальным СА, раз ты такой умный) чтобы они _НЕ_ выпускали сертификаты разрешающие подключатся к твоим серверам?
> Я лично нисколько, но как корпорация — тыщ 10 за SLA заплатил
> бы с порога. Правда, неясно куда деньги нести,вот в каждый СА и нести.
по 10 тысяч
каждую неделю.
Осталось дождатся новостей когда там найдут дыру и будут входит по мастер ключу везде.
Как работают ключи ssh тяжело погуглить, прежде чем такой бред писать?
Может еще найдут мастер пароль от всех ssh в мире? Мало ли.
> Как работают ключи ssh тяжело погуглить, прежде чем такой бред писать?
> Может еще найдут мастер пароль от всех ssh в мире? Мало ли.осталось понять что это старые ключи работали по другому, а _НОВЫЕ_ будут вот так.
Есть же PKIX-SSH
нашаHIBA.
Больше зондов от гугла=больше уязвимостей в том что и так уязвимо.
Чего-то люди совсем уже поехали. Google опубликовал разработку и за это они хейтят Google. Нет бы форкнуть и исправить то, что не нравится; либо вообще проигнорировать новость, если им эта разработка не нужна (ибо ведь никуда не форсится). Но ведь нет, надо фантазировать, что это завязка на Google-вые CA и прочие теории заговора.