Comments 14
Хаб: Информационная безопасность
Качаем и запускаем скрипт установки:
wget -qO- "https://github.com/openpubkey/opkssh/blob/main/scripts/install-linux.sh" | sudo bash
Вы серьёзно?
Обратная сторона такого решения - зависимость от кейклока. Достаточно положить сервер с ним и схема превращается в тыкву без альтернативных способов входа.
Такова участь любого централизованного решения управления доступами. Но никто не мешает вам настроить альтернативные способы входа. Можно указать несколько OpenID-провайдеров, можно ходить по паролю, можно быстренько раскидать ключи на критичные сервера. Quick start guide в статье - это минимальный набор команд для "попробовать". Дальше можно и нужно корректировать решение под свои хотелки и требования
безопасников никогда не интересовали подобные "мелочи"
как впрочем судя по curl xxx | sudo bash их и безопасность не интересует. в нормальных инфраструктурах у юзверя вообще нет возможности дёрнуть что-то с sudo.
чем это лучше чем аутентификация по ключам которые берутся из ldap и имеют срок жизни решительно непонятно, зато шайнинью Проект хоть еще и не дорос до версии 1.0....
Кто тебе мешает настроить резервную учетку с классическими ключами и просто не пользоваться ей, ключ хранить в сейфе чтобы не утёк.
Как вы собрались положить реплицируемые поды?
Интересное замечание. Просто обычно keycloak располагают внутри закрытого сетевого контура и это совсем не демилитаризованная зона, а приватная сеть доступная при подключении через тоннель. Кроме этого сам keycloak поддерживает репликацию из коробки.
Когда у вас около десяти серверов и более менее устоявшийся коллектив без постоянной текучки кадров и непонятных хотелок, процесс смены ключей (паролей) SSH может быть довольно простым и не таким частым (ansible role - самый распространённый вариант). А когда у вас с полсотни серверов и постоянно надо давать и забирать права доступа, высока вероятность запутаться и допустить ошибку.
Также keycloak поддерживает MFA (SMS, Email, TOTP, WebAuthn) поэтому можно настроить довольно надёжную схему. Но если выставить бездумно сервер IAM/IdP, собранный на коленке и запущенный через docker-compose, тогда остаётся уповать только на чудо.
Пароли ненадежны. Они могут утечь или быть быть перехвачены, удаленная система может быть подвержена брутфорс-атакам.
А в keycloak вы как авторизуетесь?
Согласен, по паролю :-) Но одно дело вводить пароль на одном доверенном ресурсе, и совсем другое - на сотне не прям чтоб доверенных. Уверен, многие просто игнорируют предупреждения о смене открытого SSH-ключа сервера и просто принимают новый )
Так что тут тоже не все так однозначно. Поэтому повторюсь - я не агитирую за это решение, а просто рассказываю новом способе авторизации. Решение о его использовании каждый должен принимать для себя сам
Использовать 2FA? Keycloak это поддерживает.
Впрочем, как и ssh
Утечка приватного ключа, как и утечка пароля, может позволить закрепиться злоумышленнику во внутренней инфраструктуре.
а может и не позволить. если приватный ключ не беспарольный, а закрыт хорошей не-словарной пассфразой символов на 200.
Автоматически открывается страница Keycloak в браузере по умолчанию
текнолоджия для локалхоста с DE
Получается что-то типа One-time SSH passwords в Vault, которому также нужен агент на сервере и клиенте?
Teleport видели?
SSH с авторизацией в Keycloak? Легко