SSH с авторизацией в Keycloak? Легко

Привет, уважаемый %username%! Уважаю твое личное время, поэтому без лишних слов — сразу к делу. В этой статье я кратко опишу, как настроить доступ к удаленному серверу по SSH с использованием Keycloak. Разберем, в чем преимущества этого решения и что именно происходит в процессе такой авторизации.

[От,С]сылки

Будем использовать open-source решение от Cloudflare — OPKSSH (OpenPubkey SSH):

ссылка на репозиторий, тыц
ссылка на пост в официальном блоге: тыц
статья про OpenPubkey на хабре: тыц (согласитесь, не густо)

Quick start guide

Серверная часть

Качаем и запускаем скрипт установки:

wget -qO- "https://github.com/openpubkey/opkssh/blob/main/scripts/install-linux.sh" | sudo bash

Укажем Keycloak в качестве провайдера OpenID. Все настройки можно найти в папке /etc/opk. Заполним файл /etc/opk/providers:

# Issuer Client-ID expiration-policy https://keycloak.corp.local/realms/opkssh OPKSSH 24h

Добавляем тестового пользователя в систему:

sudo useradd -m -s /bin/bash opkssh_user sudo passwd -l opkssh_user  # Отключаем парольный вход для пущей безопасности

Разрешим пользователю авторизоваться через OPKSSH. В параметрах команды opkssh add укажем локального пользователя, его адрес электронной почты и issuer URL:

sudo opkssh add opkssh_user opkssh_user@corp.local https://keycloak.corp.local/realms/opkssh

Keycloak

Создаем нового клиента через админ-панель:

Client ID: OPKSSH
Client Protocol: openid-connect
Valid redirect URL: http://localhost:3000/*

Клиентская часть (в моем случае это Windows 10, также поддерживается Linux и MacOS)

Качаем исполняемый файл для нашей операционной системы:

curl https://github.com/openpubkey/opkssh/releases/latest/download/opkssh-windows-amd64.exe -Lo opkssh.exe

Скачанный файл не требует установки, мы будем запускать его из командной строки каждый раз при необходимости авторизоваться в Keycloak. Возможно, стоит позаботиться о том, чтобы он лежал в директории, указанной в системной переменной PATH. Я ограничился тем, что разместил файл в своей домашней папке.

Следующим шагом создадим файл конфигурации %USERPROFILE%\.opk\config.yml:

opkssh login --create-config

В файле конфигурации удалим ненужных провайдеров (в моем случае всех) и добавим Keycloak:

--- default_provider: keycloak  providers:   - alias: keycloak     issuer: https://keycloak.corp.local/realms/opkssh     client_id: OPKSSH     client_secret: bla-bla-bla-secret     redirect_uris:       - http://localhost:3000/login-callback

На этом настройка всех компонент закончена, можно проверять доступ.

Подключаемся к удаленному серверу с использованием OPKSSH

В командной строке инициируем процесс авторизации командой opkssh login
Автоматически открывается страница Keycloak в браузере по умолчанию
Вводим верные логин/пароль, после чего страницу можно закрывать
Приложение OPKSSH завершает свою работу
Подключаемся к удаленной системе используя встроенный в Windows SSH-клиент. Без пароля, без указания ключа или сертификата, без SMS.
Доступ активен в течении 24 часов с момента авторизации, затем процедуру авторизации в Keycloak необходимо будет повторить

Как это работает

Что происходит на стороне клиента

При выполнении команды opkssh login автоматически создаются публичный и приватный ключи.
После этого открывается окно браузера со страницей авторизации SSO (в нашем случае Keycloak). OPKSSH использует протокол OpenPubkey, добавляя в тело запроса токена только что созданный публичный ключ.
В результате успешной авторизации Keycloak возвращает токен, содержащий публичный ключ. По сути, этот токен подтверждает, что ключ создан пользователем, подтвердившим свою личность.
В папке %USERPROFILE%\.ssh сохраняется сертификат, который содержит в себе:
- публичный ключ
- токен, полученный от Keycloak.
В папке %USERPROFILE%\.ssh сохраняется сертификат, который содержит в себе приватный ключ.
При подключении к удаленному серверу по SSH, сертификаты, найденные в папке %USERPROFILE%\.ssh, автоматически используются для аутентификации и шифрования.

Что происходит на стороне сервера

SSH-сервер, получив сертификат при установлении соединения, делегирует его проверку верификатору OpenPubkey. Этот функционал предоставляет нам стандартный механизм AuthorizedKeysCommand.
Верификатор OpenPubkey извлекает из сертификата токен и проверяет:
- валидный ли токен
- не устарел ли токен (время жизни токена указывается для OpenID-провайдера в настройках OPKSSH на самом сервере)
- подписан ли токен необходимым OpenID-провайдером
- совпадает ли публичный ключ в токене и публичный ключ в сертификате
Наконец верификатор OpenPubkey извлекает из токена email и проверяет, разрешен ли доступ данному пользователю.
После всех проверок верификатор OpenPubkey в соответствии настроенным политикам разрешает или запрещает запрашиваемый доступ

Основная прелесть OpenPubkey SSH в том, что не требуется модификация ни SSH-клиента, ни SSH-сервера, ни OpenID-провайдера.

Что еще умеет OPKSSH

Проект хоть еще и не дорос до версии 1.0, но активно развивается и поддерживается.

Вот некоторые из неупомянутых мной возможностей:

Одновременное использование нескольких OpenID-провайдеров.
Использование групп из oidc для принятия решения о предоставлении доступа.
Поддержка собственных плагинов, позволяющих добавить дополнительную логику принятия решения о предоставлении доступа.
Предоставление доступа под необходимой учетной записью авторизованному пользователю без установки ключей и передачи паролей.

Для чего все это надо

Пароли ненадежны. Они могут утечь или быть перехвачены, удаленная система может быть подвержена брутфорс-атакам.

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

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

Сертификаты, которые генерируются в процессе использования OPKSSH, имеют короткое время жизни и не требуют развернутой PKI. Настройка такого доступа при наличии готового решения SSO требует минимум времени и усилий, а эффект по усилению информационной безопасности проявляется сразу.

Использовать ли такой подход в своей инфраструктуре — решать вам.

ссылка на оригинал статьи https://habr.com/ru/articles/940114/