Открыть сервис
Главная → Блог → OpenSSH CA

OpenSSH CA

OpenSSH CA — это механизм централизованного управления аутентификацией в протоколе SSH, реализованный в составе пакета OpenSSH. Он позволяет использовать инфраструктуру открытых ключей (PKI) для подписи сертификатов пользователей и хостов, что даёт возможность гибко управлять доступом к серверам без необходимости распространять и обновлять отдельные публичные ключи на каждом узле.

История

Идея использования сертификатов для SSH возникла как решение проблемы масштабирования аутентификации. Традиционный метод с использованием файлов authorized_keys требует копирования публичного ключа каждого пользователя на каждый сервер, что при большом количестве машин становится трудоёмким и небезопасным. В 2010-х годах разработчики OpenSSH (входящего в проект OpenBSD) добавили поддержку сертификатов на основе PKI. Первая реализация появилась в OpenSSH 5.4 (2010 год) и с тех пор активно развивалась. В отличие от X.509, используемого в TLS/SSL, SSH-сертификаты имеют собственный формат, что упрощает их реализацию и интеграцию с существующими SSH-ключами.

Принцип работы

OpenSSH CA основан на модели доверенного центра сертификации (Certificate Authority, CA). В этой модели существует один или несколько центров, которые подписывают сертификаты пользователей и хостов. Серверы и клиенты доверяют только тем ключам, которые подписаны известным им CA.

Основные компоненты

  • Центр сертификации (CA): приватный ключ, используемый для подписи сертификатов. Хранится в секрете и используется только для подписи.
  • Сертификат пользователя: публичный ключ пользователя, подписанный CA, с указанием имени пользователя, срока действия, списка разрешённых хостов и других параметров.
  • Сертификат хоста: публичный ключ сервера, подписанный CA, с указанием имени хоста (FQDN) и срока действия.
  • Файл доверенных CA: на сервере (/etc/ssh/ssh_config или ~/.ssh/known_hosts) указываются публичные ключи CA, которым доверяет сервер.
  • Файл доверенных CA для пользователей: на сервере (/etc/ssh/sshd_config) указывается параметр TrustedUserCAKeys, содержащий список публичных ключей CA, которым доверяет сервер для аутентификации пользователей.

Процесс аутентификации

  1. Подготовка: администратор генерирует пару ключей CA (приватный и публичный). Публичный ключ CA распространяется на все серверы (в TrustedUserCAKeys).
  2. Выпуск сертификата: пользователь генерирует свою пару SSH-ключей и отправляет публичный ключ администратору CA. Администратор подписывает его с помощью приватного ключа CA, создавая сертификат пользователя. Сертификат содержит:
  • Публичный ключ пользователя.
  • Имя пользователя (или список имён) для входа.
  • Срок действия (например, valid-after и valid-before).
  • Список разрешённых хостов (опционально).
  • Дополнительные ограничения (например, force-command, permit-agent-forwarding).
  1. Подключение: пользователь подключается к серверу, предоставляя свой сертификат (вместо обычного публичного ключа). Сервер проверяет подпись сертификата с помощью публичного ключа CA из TrustedUserCAKeys. Если подпись верна, сервер проверяет срок действия, имя пользователя и другие параметры. Если всё совпадает, доступ разрешается.
  2. Проверка хоста: при первом подключении к серверу клиент может проверить сертификат хоста, подписанный CA. Это позволяет избежать предупреждений о неизвестном хосте (если сертификат подписан доверенным CA).

Преимущества

  • Централизованное управление: администратор может отозвать доступ, просто перестав подписывать сертификаты для конкретного пользователя или хоста. Не требуется изменять файлы authorized_keys на каждом сервере.
  • Гибкость: сертификаты могут содержать ограничения (например, разрешённые команды, время действия, список хостов). Это позволяет реализовать тонкую настройку прав доступа.
  • Безопасность: приватные ключи CA можно хранить на аппаратном модуле безопасности (HSM) или в защищённом хранилище. Сертификаты имеют ограниченный срок действия, что снижает риск от утечки ключей.
  • Масштабируемость: при добавлении нового сервера достаточно добавить его публичный ключ CA в TrustedUserCAKeys. Пользователи не требуют дополнительной настройки на сервере.
  • Снижение нагрузки на администрирование: отпадает необходимость вручную копировать ключи на каждый сервер. Пользователи могут самостоятельно генерировать сертификаты через CA (например, через веб-интерфейс или API).

Недостатки и ограничения

  • Единая точка отказа: если приватный ключ CA скомпрометирован, злоумышленник может подписывать любые сертификаты. Требуется строгая защита CA.
  • Сложность внедрения: для небольших инфраструктур настройка CA может быть избыточной. Требуется обучение администраторов.
  • Зависимость от CA: при недоступности CA выпуск новых сертификатов невозможен. Необходимо резервирование CA.
  • Отсутствие стандартизации: формат SSH-сертификатов не совместим с X.509, что может усложнить интеграцию с существующими PKI-системами.
  • Управление отзывом: OpenSSH не поддерживает CRL (Certificate Revocation List) или OCSP (Online Certificate Status Protocol) для сертификатов. Отзыв возможен только через удаление сертификата из файла authorized_keys или через изменение TrustedUserCAKeys. Однако можно использовать короткие сроки действия сертификатов (например, 24 часа) для минимизации последствий утечки.

Применение

OpenSSH CA широко используется в крупных IT-инфраструктурах, где требуется управление доступом к сотням и тысячам серверов. Примеры:

  • Облачные провайдеры: для управления доступом к виртуальным машинам.
  • DevOps-команды: для автоматизации развёртывания и управления конфигурациями (например, с помощью Ansible, Chef, Puppet).
  • Корпоративные сети: для централизованного управления доступом к серверам в дата-центрах.
  • Системы непрерывной интеграции (CI/CD): для автоматической генерации сертификатов для агентов сборки.

Реализации

OpenSSH CA является встроенной функцией самого OpenSSH. Для управления CA существуют различные инструменты и скрипты:

  • ssh-keygen: утилита для генерации ключей и подписи сертификатов (команды ssh-keygen -s и ssh-keygen -L).
  • ssh-ca: библиотека на Python для автоматизации работы с CA.
  • Step CA: сторонний инструмент, который может выступать в роли CA для SSH (поддерживает как X.509, так и SSH-сертификаты).
  • Hashicorp Vault: может использоваться как CA для SSH, предоставляя API для выпуска сертификатов.

Интересные факты

  • OpenSSH CA использует собственный формат сертификатов, который не связан с X.509. Это сделано для упрощения и повышения производительности.
  • Сертификаты могут быть подписаны как с использованием RSA, так и с использованием криптографии на эллиптических кривых (ECDSA, Ed25519).
  • В OpenSSH 8.0 (2019 год) была добавлена поддержка сертификатов для протокола SSHFP (SSH Fingerprint) для DNS.
  • Механизм CA в OpenSSH не требует установки дополнительного программного обеспечения — всё встроено в стандартный пакет OpenSSH.

Источники

  • OpenSSH Manual: ssh-keygen(1), sshd_config(5), ssh_config(5)
  • Руководство по OpenSSH CA (OpenBSD)
  • Документация проекта OpenSSH (openssh.com)
  • Статья «Using OpenSSH Certificate Authentication» (DigitalOcean, 2018)
  • Книга «SSH Mastery: OpenSSH, PuTTY, Tunnels and Keys» (Michael W. Lucas, 2018)

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы