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

[От,С]сылки

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

1. ссылка на репозиторий, тыц

2. ссылка на пост в официальном блоге: тыц

3. статья про 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 требует минимум времени и усилий, а эффект по усилению информационной безопасности проявляется сразу.

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