The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Google опубликовал HIBA, надстройку над OpenSSH для авторизации на основе сертификатов

21.09.2021 12:25

Компания Google опубликовала исходные тексты проекта HIBA (Host Identity Based Authorization), предлагающего реализацию дополнительного механизма авторизации для организации доступа пользователей по SSH в привязке к хостам (проверки, разрешён или нет доступ к конкретному ресурсу при аутентификации по открытым ключам). Интеграция с OpenSSH обеспечивается через указание обработчика HIBA в директиве AuthorizedPrincipalsCommand в /etc/ssh/sshd_config. Код проекта написан на языке Си и распространяется под лицензией BSD.

HIBA использует штатные механизмы аутентификации на основе сертификатов OpenSSH для гибкого и централизованного управления авторизацией пользователей в привязке к хостам, но не требует при этом периодического изменения файлов authorized_keys и authorized_users на стороне хостов, к которым осуществляется подключение. Вместо хранения списка допустимых публичных ключей и условий доступа в файлах authorized_(keys|users), HIBA интегрирует сведения о привязке пользователей к хостам непосредственно в сами сертификаты. В частности, предложены расширения для сертификатов хостов и сертификатов пользователей, в которых хранятся параметры хостов и условия предоставления доступа пользователей.

Проверка на стороне хоста инициируется через вызов обработчика hiba-chk, прописанного в директиве AuthorizedPrincipalsCommand. Данный обработчик декодирует интегрированные в сертификаты расширения и на их основе принимает решение о предоставлении или блокировании доступа. Правила доступа определяются централизованно на уровне удостоверяющего центра (CA) и интегрируются в сертификаты на этапе их генерации.

На стороне удостоверяющего центра ведётся общий список доступных полномочий (хостов к которым разрешено подключение) и список пользователей, которым разрешено воспользоваться данными полномочиями. Для генерации заверенных сертификатов с интегрированной информацией о полномочиях предложена утилита hiba-gen, а функциональность необходимая для создания удостоверяющего центра вынесена в скрипт hiba-ca.sh.

Во время подключения пользователя указанные в сертификате полномочия подтверждаются цифровой подписью удостоверяющего центра, что позволяет выполнить все проверки целиком на стороне целевого хоста, к которому осуществляется подключение, без обращения к внешним службам. Список открытых ключей удостоверяющего центра, заверяющего SSH-сертификаты, указывается через директиву TrustedUserCAKeys.

Помимо прямой привязки пользователей к хостам, HIBA позволяет определить более гибкие правила доступа. Например, к хостам можно привязать такую информацию как местоположение и тип сервиса, а при определении правил доступа пользователей разрешить подключени ко всем хостам с заданным типом сервиса или к хостам в указанном месте.



  1. Главная ссылка к новости (https://opensource.googleblog....)
  2. OpenNews: Mozilla внедряет CRLite для проверки проблемных TLS-сертификатов
  3. OpenNews: Google представил Key Transparency, альтернативу серверам криптографических ключей
  4. OpenNews: В Chrome планируют добавить собственное хранилище корневых сертификатов
  5. OpenNews: Red Hat и Google представили Sigstore, сервис для криптографической верификации кода
  6. OpenNews: В клиентском ПО удостоверяющего центра MonPass выявлен бэкдор
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/55841-ssh
Ключевые слова: ssh, auth
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (53) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Arcade (ok), 12:53, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Не понял чо нового по сравнению с SSH CA: вроде всё то же самое.
     
     
  • 2.7, Crazy Alex (ok), 13:12, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Я тмк понимаю, тут проще напихать какие-то произвольные признаки и по ним матчить
     
  • 2.11, Анто Нимно (?), 13:17, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ничего нового. CA, приносящий доход, уже существует. Оставалось просто соединить.
     

  • 1.2, нах.. (?), 12:55, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Яссно, еще один зонд. Буду знать врага в лицо и выпиливать.
     
     
  • 2.6, Crazy Alex (ok), 13:09, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Ни хрена тебе не ясно. Что и откуда ты выпиливать собрался, если это отдельная приблуда, разворачиваемая владельцем инфраструктуры там, где ему надо?
     
     
  • 3.10, Анто Нимно (?), 13:15, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Это на бабло развод в будущем. Есть конторы, торгующие сертами и пропри-прошивки с сертами... Профит.
     
     
  • 4.22, Аноним (22), 15:42, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    У ALPHABET не кислые дольки почти в каждом CA.
    Почему бы гуглу не возглавить openssh?
     
  • 4.31, Тфьу (?), 17:07, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    никто не заставляет покупать платный сертификат, можно использовать свой СА
     
     
  • 5.44, Аноним (44), 21:44, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Не можно, а нужно.
     
  • 5.45, кокпок (?), 21:57, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Варианта использовать НЕ свой CA в данном случае нету, он всегда будет свой.
     
  • 2.13, Аноним (13), 13:19, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Будешь выпиливать отовсюду OpenSSH и ставить Telnet? Я слышал что где-то глубоко в недрах сиски практикуют так называемый "Telnet over SSL", отпишись когда попробуешь.
     
     
  • 3.15, нах... (?), 13:57, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • –3 +/
    выпилил. телнет работает отлично
     
     
  • 4.18, PnD (??), 14:20, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Стесняюсь спросить (но спрошу).
    А telnetd запускаете из-под православного inetd (xinetd)? Или обернув б-мерзким systemd [Socket]?

    Так-то да. Чего ж не обойтись. Даже в ssl можно обернуть. Правда, есть нюанс: stderr так не получить в отдельном fd.

    Ой, а может он у вас на железках вроде cs2950? Тогда, конечно…

     
  • 3.16, aa (?), 13:57, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    как будто для SSL под телнетом не нужны сертификаты/СА и всё такое
     
     
  • 4.53, Аноним (13), 10:27, 22/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Так же как OPENSSH, но человек хочет быть другим, не таким как все.
     
  • 2.43, Аноним (-), 21:42, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Я вражескими поделками ваще не пользуюсь уже лет семь, чего и вам желаю. Вы будете улыбаться, слыша слово ... да и ваще все эти buzzwords. Вы же умны, так применяйте свой ум.
     
     
  • 3.46, кокпок (?), 21:59, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А чем пользуетесь берестой и углем?
     
  • 3.51, Прохожий (??), 08:03, 22/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Скрепы - наше всё.
     
  • 3.56, Аноним (-), 17:04, 22/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Правильно! Гугл давно перешёл все рамки приличия.
     

  • 1.4, scor (ok), 13:01, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > все проверки целиком на стороне целевого хоста ... без обращения к внешним службам

    ага. Пока не понадобится отозвать какой-то сертификат. Тут и начнётся "здравствуй x509". Ну или CRL-ки переодически раскладывать на каждый хост. Тогда не понятно, чем это отличается от сейчас.

     
     
  • 2.5, Crazy Alex (ok), 13:08, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    От сейчас - очень понятно, чем. Ты забил в сертификат "годен для подключения к хостам a, b, c" - и так оно и отработает. Или прибил признак какой-то - и нужным хостам задаёшь - пускать по сертификатам с данным значением данного признака.

    А отзыв - не страшнее, чем сейчас. Сейчас надо по всем хостам из всех authorized_keys выкинуть соответствующие записи, автоматическиое обновление их CRL ничем не хуже.

     
     
  • 3.8, scor (ok), 13:14, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ты забил в сертификат "годен для подключения к хостам a, b, c" - и так оно и
    > отработает.

    Или просто не положил паблик пользователя на хост...

    > А отзыв - не страшнее, чем сейчас. Сейчас надо по всем хостам
    > из всех authorized_keys выкинуть соответствующие записи, автоматическиое обновление
    > их CRL ничем не хуже.

    Т.е. нужно точно также ходить по всем хостам и что-то там править? Ну т.е. все теже проблемы, что и сейчас, только в новой обёртке и файлы по другому называются. Окай.:)

     
     
  • 4.14, Аноним (14), 13:56, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Глобальная разница в том, что оаньше ты обходил все хосты, чтобы добавить и чтобы удалить. Тут можно обходить хосты только в случае незапланированного принудительного удаления.


    Плюс, скорее всего, как в OAuth2, подписи CA сделают короткоживущими, типа, пяти минут. В случае компрометации ключа, его блокируют на CA и через пять минут, когда на нем протухнет подпись, никто не сможет ее восстановить и автоматически ключ станет недействителен на всех хостах.

     
  • 4.27, OpenEcho (?), 16:31, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все наоборот. Хосты бегают за обновой.
    Хосты переодически шлют GraphQL запрос на "базу" со своим состоянием и если что есть к обнове, пикапают (и CRL в том числе). Если на базе нет коннектов с какого-то хоста то это аларм, т.е мониторинг & контрол all-in-one
     
     
  • 5.34, scor (ok), 17:50, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Все наоборот. Хосты бегают за обновой.
    > Хосты переодически шлют GraphQL запрос на "базу" со своим состоянием и если
    > что есть к обнове, пикапают (и CRL в том числе).

    Это всё только на бумаге работает. В реальной жизни всё печальней обычно. Что делать хосту, если он не смог обновить CRL? Не пускать никого пока не обновит? Или пускать основываясь на старой версии CRL? И любой из этих варинтов плох, к сожалению.


    > Если
    > на базе нет коннектов с какого-то хоста то это аларм, т.е
    > мониторинг & контрол all-in-one

    В каких-то масштабах это наверное даже работает и выглядит прикольно. Только всё вот это, на ровном месте требует создания и поддержания дополнительной инфраструктуры, которую нужно мейнтейнить, мониторить и на ноды которой тоже нужно как-то попадать. А в замен предлагается схема с дополнительной авторизацией, которая не понятно какие бонусы даёт и к тому же, в общем случае, не работает.

    Ну и, возвращаясь к старту треда. Это вовсе не выглядит как "все проверки целиком на стороне целевого хоста ... без обращения к внешним службам". То, что можно построить бессмысленных велосипедов любой сложности никто и не спорит, так-то.:)

     
  • 2.23, Аноним (22), 15:50, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Тогда не понятно, чем это отличается от сейчас.

    Сейчас о вас заботы нету. Будет.

    Сначала сделаем надстройку
    Потом её протащим как стандарт де-факто
    Надстройка становится неотъемлемой частью проекта
    Рулим проектом и его аудиторией
    Сдохнет всё - не жалко, вложения минимальны, чужой проект сдох
    Или получим прибыль, просто здорово

    А то как же пользователи и без заботы?

    Сейчас про OpenSSH, но для гугла это один из стандартных подходов

     
     
  • 3.54, странадураков (?), 12:44, 22/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сначала сделаем надстройку
    > Потом её протащим как стандарт де-факто
    > Надстройка становится неотъемлемой частью проекта

    казалось бы, причём здесь всего-лишь новый нескучный инит, новый безопасный язык,.. новый....

     

  • 1.21, gogo (?), 15:18, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-то я не пойму, если таким сертом завладел злоумышленник и ты об этом знаешь, то что делать?
    Из описания я не вижу, как можно заблокировать конкретный сертификат. Разве что только удалить ключи удостоверяющего центра.
     
  • 1.25, Аноним (25), 16:21, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Какой-то сраный велосипед.
    1) отзыв сертов (об этом уже писали на форуме)
    2) что делать, если захотим поменять доступ конкретному серту? Генерить новый серт ? Старый отзывать ?

    И да, походу отзыв нужно делать на ВСЕХ хостах отдельно


    Прикрутить LDAP к sshd в гугле не осилили, создают ведосипеды

     
  • 1.26, Совсем не аноним (?), 16:28, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем, когда есть FreeIPA или LDAP?
     
     
  • 2.29, Аноним (29), 16:42, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Затем, чтобы не надо было иметь целый отдельный сервис, который надо обслуживать, следить за безопасность и доступностью, выписывать и распространять сертификаты. Позволяет пропустить бессмысленные телодвижения и проверить валидность пользователя прямо на хосте, без использования внешних ресурсов. Админам высоконагруженных локалхостов не понять.
     
     
  • 3.32, Тфьу (?), 17:09, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    но нужно следить за своим СА и за ЦРЛками, следить, чтобы они обновлялись своевременно на всех хостах.
     
     
  • 4.39, Аноним (39), 19:24, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А с LDAP не нужно что ли?
     

  • 1.28, Аноним (29), 16:38, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Годнейшая штука, реально не хватает такой. Надеюсь её как можно скорее интегрируют сразу в OpenSSH.
     
  • 1.30, anonymous (??), 16:42, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    openssh поддерживает x509. Нахрена тут нужен этот велосипед?
     
  • 1.35, Аноним (-), 18:23, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Код проекта написан на языке Си

    Переписать на руст, затем удалить и снова переписать. Возможно, тогда и станет безопасным.

    // b.

     
  • 1.36, Аноним (36), 18:43, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    https://www.earth.li/~noodles/blog/2019/04/totp-auth.html

    А что насчет SSH 2FA TOTP, все уже несекурно?)
    Там либа от Гугла но она никак с ним не связана, никуда не стучит, просто генерирует числа на стороне сервера.
    На стороне клиента можно использовать любой 2фа софт или Yubikey.

     
  • 1.37, AnonymPatient (?), 18:59, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>Проверка на стороне хоста инициируется через вызов обработчика hiba-chk, прописанного в директиве AuthorizedPrincipalsCommand.
    >>Данный обработчик декодирует интегрированные в сертификаты расширения и на их основе принимает решение о предоставлении или блокировании доступа.
    >>Правила доступа определяются централизованно на уровне удостоверяющего центра (CA) и интегрируются в сертификаты на этапе их генерации.

    Не озвучены пара фундументальных вещей:
    - где можно записаться в бенефициары CA ?
    - сколько сольдо будет стоить абонемент на 10-хостов ?

     
     
  • 2.38, ibaca (?), 19:20, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Нисколько, вот пример:
    https://github.com/cloudtools/ssh-ca
     

  • 1.40, Андрей (??), 20:14, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хиба цэ шо то новое?
     
     
  • 2.41, Анончик (?), 20:40, 21/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    SSH CA в другой руке
     

  • 1.48, Атон (?), 23:13, 21/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Правила доступа определяются централизованно на уровне удостоверяющего центра (CA) и интегрируются в сертификаты на этапе их генерации.

    владелец СА конечно гугл, будет брать деньги за каждый сертификат, гугл в любой момент может по своему желанию отозвать мой сертификат, или исключить из моего сертификата любой мой хост?

    годно!

     
     
  • 2.49, Анончик (?), 00:31, 22/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >владелец СА конечно гугл

    Да вас насильно тащат под крыло гугла ведь только гугл может быть CA.
    Других то CA нет больше.

     
     
  • 3.60, Атон (?), 21:24, 22/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >>владелец СА конечно гугл
    > Да вас насильно тащат под крыло гугла ведь только гугл может быть
    > CA.
    > Других то CA нет больше.

    название - не имеет значения.

    читай внимательно: СА выдает ПОЛЬЗОВАТЕЛЮ сертификат. пользователь с этим сертификатом коннектится к удаленному хосту. удаленный хост проверяет сертификат в СА выпустившем этот сертификат, и узнает какие права имеет этот пользователь на этом хосте.

    сколько ты готов платить гуглу (+ всем остальным СА, раз ты такой умный) чтобы они _НЕ_ выпускали сертификаты разрешающие подключатся к твоим серверам?


     
     
  • 4.62, Аноним (62), 22:09, 23/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > сколько ты готов платить гуглу (+ всем остальным СА, раз ты такой умный) чтобы они _НЕ_ выпускали сертификаты разрешающие подключатся к твоим серверам?

    Я лично нисколько, но как корпорация — тыщ 10 за SLA заплатил бы с порога. Правда, неясно куда деньги нести, сертификаты SSH не завязаны ни на какой публичный CA by design. Там даже опции такой нет, надо со своим CA приходить.

     
     
  • 5.63, Атон (?), 12:30, 24/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    >> сколько ты готов платить гуглу (+ всем остальным СА, раз ты такой умный) чтобы они _НЕ_ выпускали сертификаты разрешающие подключатся к твоим серверам?
    > Я лично нисколько, но как корпорация — тыщ 10 за SLA заплатил
    > бы с порога. Правда, неясно куда деньги нести,

    вот в каждый СА и нести.
    по 10 тысяч
    каждую неделю.

     

  • 1.50, Ivan_83 (ok), 02:43, 22/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Осталось дождатся новостей когда там найдут дыру и будут входит по мастер ключу везде.
     
     
  • 2.52, Аноним (36), 09:40, 22/09/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как работают ключи ssh тяжело погуглить, прежде чем такой бред писать?
    Может еще найдут мастер пароль от всех ssh в мире? Мало ли.
     
     
  • 3.59, Атон (?), 21:16, 22/09/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Как работают ключи ssh тяжело погуглить, прежде чем такой бред писать?
    > Может еще найдут мастер пароль от всех ssh в мире? Мало ли.

    осталось понять что это старые ключи работали по другому, а _НОВЫЕ_ будут вот так.

     

  • 1.55, 0x501D (?), 16:09, 22/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть же PKIX-SSH
     
  • 1.57, Kenneth (?), 17:23, 22/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    нашаHIBA.
     
  • 1.58, Аноним (58), 17:28, 22/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Больше зондов от гугла=больше уязвимостей в том что и так уязвимо.
     
  • 1.61, anonymous (??), 12:04, 23/09/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чего-то люди совсем уже поехали. Google опубликовал разработку и за это они хейтят Google. Нет бы форкнуть и исправить то, что не нравится; либо вообще проигнорировать новость, если им эта разработка не нужна (ибо ведь никуда не форсится). Но ведь нет, надо фантазировать, что это завязка на Google-вые CA и прочие теории заговора.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру