Централизация доступа в Linux: LDAP, SSH CA или Ansible

Что на самом деле нужно при централизации учетных записей Linux

Большинство администраторов, приступая к централизации учетных записей Linux, преследуют одну цель: добавить пользователя один раз, удалить один раз и обеспечить согласованность на всех серверах. Служба каталогов решает эту задачу. Однако для парка из 6 VPS это самый ненадежный способ, так как недоступность каталога может одновременно заблокировать вход на все машины.

Существует три подхода, обеспечивающих принцип «изменил один раз — применилось везде». Можно развернуть службу каталогов, например OpenLDAP или FreeIPA, и использовать SSSD (system security services daemon) на каждом хосте. Можно выпускать краткосрочные SSH-сертификаты с помощью собственного центра сертификации (CA). Можно распространять учетные записи пользователей и файлы authorized_keys через систему управления конфигурациями. В этой статье каждый метод оценивается по скорости отзыва доступа, поведению во время сбоев, политике sudo, аудиту и стоимости внедрения, а также даются рекомендации в зависимости от размера парка серверов, вместо выбора единственного «победителя».

Проанализируйте задачу перед установкой OpenLDAP

LDAP (lightweight directory access protocol) централизует управление учетными данными: имена пользователей, числовые идентификаторы (UID), членство в группах и, как правило, пароли. Это его основная функция. Он не занимается распространением публичных ключей SSH, не определяет, кто имеет право запускать sudo, и не ведет учет того, кто и куда вошел в систему. Каждая из этих задач требует отдельной настройки поверх базовой системы. Команды часто устанавливают OpenLDAP, ожидая получить готовую систему контроля доступа, но вместо этого получают базу данных со схемой, синтаксисом правил доступа и топологией репликации, которые необходимо обслуживать.

Поэтому сформулируйте реальные требования перед выбором решения. Обычно они сводятся к следующему: уволенный сотрудник должен терять доступ в тот же день, новый сотрудник должен получать доступ только к нужной группе хостов, а вы должны иметь возможность ответить на вопрос «кто заходил на этот сервер во вторник» спустя три месяца. Расставьте приоритеты. От них зависит выбор инструмента.

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

Вариант первый: каталог с SSSD на каждом хосте

Схема проста. Один LDAP-сервер (или два, если вы хотите, чтобы авторизация работала после перезагрузки) хранит учетные записи пользователей. На каждом хосте запущен SSSD, который подключается к NSS (name service switch) для разрешения имен id alice и к PAM (pluggable authentication modules) для работы аутентификации. Когда getent passwd alice возвращает пользователя, для которого нет записи в /etc/passwd, компоненты системы связываются воедино.

Ваши реалистичные варианты на август 2026 года:

• OpenLDAP: «чистый» каталог. Вы самостоятельно проектируете дерево, загружаете схемы, настраиваете TLS (transport layer security), пишете списки контроля доступа и настраиваете репликацию. Руководство администратора OpenLDAP 2.6 является основным справочником, и его объем оправдан.
• FreeIPA: 389 Directory Server, MIT Kerberos, центр сертификации, DNS и управление доступом к хостам в одном пакете. Это решение «из коробки» закрывает гораздо больше задач. Оно требует собственных DNS-записей и стабильного полного доменного имени (FQDN), а его естественная среда — семейство RHEL. См. freeipa.org.
• Продукт SSO (single sign-on) с интерфейсом LDAP. LDAP-провайдер в Authentik предоставляет доступ к базе пользователей по протоколу LDAP и содержит документацию по настройке SSSD в качестве клиента, что позволяет использовать единый список пользователей как для веб-приложений, так и для входа в оболочку (shell). Keycloak выполняет федерацию из существующего LDAP-каталога, а не выступает в роли сервера каталогов — это деталь, которая часто становится неожиданностью. Сравнение self-hosted SSO-серверов описывает это различие, а развертывание Authentik на собственном сервере содержит инструкции по установке.

Два момента легко упустить из виду. Во-первых, публичные SSH-ключи могут храниться в каталоге: настройте ldap_user_ssh_public_key и укажите AuthorizedKeysCommand в конфигурации sshd на sss_ssh_authorizedkeys. Если этого не сделать, пароли будут централизованы, а ключи останутся разбросанными по домашним директориям. Во-вторых, access_provider по умолчанию имеет значение permit, что означает, что каждый пользователь из каталога может войти на любой хост, который вы к нему подключили. Таким образом, добавление нового сервера молчаливо предоставляет доступ к оболочке всем пользователям, пока вы не настроите реальный провайдер доступа.

[domain/example.com]
cache_credentials = true
access_provider = simple
simple_allow_groups = linux-admins

[pam]
offline_credentials_expiration = 7

Вариант два: центр сертификации SSH

Одна пара ключей подписывает сертификаты. Каждый сервер доверяет открытому ключу CA через две строки в sshd_config. Не нужно устанавливать пакеты, запускать демоны или распространять файлы для каждого пользователя. OpenSSH поддерживает сертификаты начиная с версии 5.4, поэтому они есть в любом современном дистрибутиве.

TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Сертификат — это подписанное утверждение об открытом ключе. Он содержит идентификатор ключа (имя пользователя), список принципалов (имена учетных записей, под которыми этот ключ может войти в систему), период действия и параметры, такие как force-command или source-address. Файл AuthorizedPrincipalsFile на каждом хосте определяет, какие принципалы могут стать конкретным локальным пользователем, поэтому один и тот же сертификат может давать права администратора на одной машине и не давать никаких прав на другой. Перед созданием инструментов на базе этой технологии стоит полностью изучить раздел CERTIFICATES в руководстве ssh-keygen.

ssh-keygen -s /etc/ssh/user_ca -I alice@example.com -n deploy -V +8h -z 1042 id_ed25519.pub

Самый важный флаг здесь — -V. Руководство прямо говорит о значении по умолчанию: сертификаты действительны с начала эпохи Unix до далекого будущего. Если забыть про -V, вы выдадите не временный доступ, а постоянные учетные данные, доверие к которым сервер не прекратит никогда. Проверяйте результат работы вашего скрипта подписи с помощью ssh-keygen -L -f id_ed25519-cert.pub и читайте строку срока действия, прежде чем доверять скрипту.

Подписывайте также ключи хостов. HostCertificate на каждом сервере плюс одна строка @cert-authority в вашем локальном known_hosts избавляют от запроса «подлинность хоста не может быть установлена» для любого сервера, который вы когда-либо создадите, а вместе с ним — от привычки вводить yes не глядя. Эта привычка становится реальным риском, когда вы управляете большим количеством серверов Linux, чем можете перечислить по именам.

Важный нюанс: сертификат авторизует вход, но не создает учетную запись Unix. Локальная учетная запись уже должна существовать: созданная системой управления конфигурациями, каталогом пользователей или как общая роль, например deploy, доступная нескольким людям. Для более сложных решений, чем простой скрипт подписи, используйте движок подписанных SSH-сертификатов в HashiCorp Vault или step-ca — оба инструмента выдают краткосрочные сертификаты после входа через SSO.

Вариант три: учетные записи и ключи через системы управления конфигурациями

Ansible, Salt или Puppet создают учетную запись, формируют authorized_keys и размещают файл в /etc/sudoers.d. Источником истины является git-репозиторий. Удаление пользователя выполняется через коммит и запуск системы.

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

Слабая сторона этого метода очевидна и требует четкого описания: корректность зависит от того, дошел ли последний запуск до хоста. Сервер, который был выключен или находился за неисправным сетевым маршрутом, сохранит ключ, который вы только что удалили, а отчет о запуске пометит его как недоступный, а не как сбойный. Именно поэтому то, как Ansible обрабатывает недоступные хосты важнее, чем кажется на первый взгляд. Во время процедуры увольнения сотрудника недоступный хост — это открытая задача, а не предупреждение, которое можно проигнорировать при прокрутке логов.

Как быстро на самом деле можно ограничить доступ пользователя?

Ни один из трех способов не завершает уже открытую сессию. Все они лишь блокируют следующий вход. Чтобы прекратить текущий доступ, завершите сессии с помощью pkill -u alice или перезагрузите сервер. Все дальнейшие рассуждения исходят из этого условия.

Каталог работает быстро в теории, но медленнее на практике из-за кэширования SSSD. Значение entry_cache_timeout по умолчанию составляет 5400 секунд, поэтому изменение членства в группе может отображаться на хосте до девяноста минут, если не запустить sss_cache -E. Хуже того, cache_credentials сохраняет хеш пароля пользователя на каждом хосте, где он авторизовался, а offline_credentials_expiration по умолчанию равен 0, что означает отсутствие ограничений. Эти два параметра по умолчанию позволяют заблокированному пользователю продолжать вход в офлайн-режиме на любом хосте, где сохранились его данные, без даты окончания доступа. Установите срок действия в количестве дней, как показано в конфигурации выше.

SSH CA работает медленнее в теории, но быстрее на практике. Вы не отзываете доступ, а просто позволяете сертификату истечь. Сертификат со сроком действия восемь часов перестанет работать через восемь часов без необходимости обращаться к хостам или опасаться, что какой-то из них будет пропущен. Если доступ нужно прекратить немедленно, создайте список отзыва ключей (KRL) с помощью ssh-keygen -k, распространите его на все хосты и укажите его в RevokedKeys. Это снова требует принудительной рассылки на все хосты, чего вы и пытались избежать, поэтому рассматривайте KRL как экстренную меру, а не как стандартную процедуру.

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

Что перестает работать, если центральный сервис недоступен?

Этот вопрос определяет выбор для небольших парков серверов, поэтому ответим на него в первую очередь.

Отказ службы каталогов — наиболее опасный сценарий. Хосты, зависящие от нее при поиске пользователей, могут отклонять попытки входа или зависать, и поскольку все хосты обращаются к одному серверу, они выходят из строя одновременно. Одна неисправная виртуальная машина может заблокировать вход везде сразу. Поэтому три вещи являются обязательными. Настройте cache_credentials = true, чтобы пользователи, которые уже входили на хост ранее, могли войти снова во время сбоя. Запустите второй сервер каталогов и укажите оба в ldap_uri. Сохраняйте на каждом хосте локальную учетную запись для экстренного доступа с собственным ключом и знайте, как получить доступ к консоли вашего провайдера в качестве последнего средства.

Поймите ограничения этого кэша, прежде чем полагаться на него. Он работает на уровне хоста и пользователя. У того, кто никогда не входил на конкретную машину, в кэше ничего нет, а у только что развернутого хоста кэш пуст, поэтому во время сбоя службы каталогов новейший сервер окажется тем, куда никто не сможет войти. На хосте команда sssctl domain-status показывает, считает ли SSSD домен доступным в данный момент.

Затем протестируйте это намеренно. Заблокируйте порт службы каталогов правилом межсетевого экрана на одном хосте, держите открытым второй терминал и попробуйте войти. Если вы не протестировали кэш и учетную запись для экстренного доступа, вы не знаете, работают ли они. Это та же дисциплина, что и в остальной части контрольного списка планового обслуживания Linux-серверов: путь восстановления, который вы никогда не проверяете, — это тот, который обязательно подведет.

SSH CA выходит из строя «мягко». Если сервис подписи недоступен, никто не сможет получить новый сертификат, но все уже выданные сертификаты продолжают работать до истечения срока их действия. Пользователи заметят проблему в начале следующего рабочего дня, а не в разгар инцидента. Серьезный сбой CA выглядит иначе: закрытый ключ CA — это ключ от всего парка серверов, поэтому он должен храниться в офлайне, на аппаратном токене или внутри сервиса, который протоколирует каждую выполненную подпись.

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

Где хранятся политики sudo?

Каталог может содержать правила sudo. Записи sudoers могут храниться в LDAP и считываться через sudo-ответчик SSSD с помощью sudoers: files sss в /etc/nsswitch.conf. FreeIPA рассматривает правила sudo как объекты первого класса. При использовании обычного OpenLDAP вы загружаете схему sudo и вручную создаете записи sudoRole. Многие команды, дошедшие до этого этапа, всё равно предпочитают хранить /etc/sudoers.d на хосте, так как это проще для чтения и сохраняет работоспособность во время сбоев сети.

SSH-сертификат ничего не говорит о привилегиях. Он лишь предоставляет доступ для входа под определенным именем пользователя, а всё, что происходит после этого, регулируется обычной локальной политикой sudo. Если вы хотите, чтобы сам сертификат ограничивал поведение, используйте force-command и source-address — это доступные инструменты, хотя они являются довольно грубыми средствами контроля.

Системы управления конфигурациями развертывают файлы в /etc/sudoers.d/ и проверяют их с помощью visudo -cf перед установкой. Это остается верным независимо от того, какой вариант идентификации вы выберете, поскольку политика sudo по своей природе привязана к конкретному хосту. Решите, кому и что разрешено, прежде чем что-либо централизовать: проектирование учетных записей с минимальными привилегиями на VPS — это работа, которую ни один из этих трех инструментов за вас не выполнит.

Что можно доказать впоследствии?

В вопросе аудита SSH CA выигрывает безоговорочно. Когда sshd принимает сертификат, он записывает идентификатор ключа и серийный номер сертификата рядом с фактом успешного входа. Таким образом, вход в общую учетную запись deploy позволяет идентифицировать конкретного пользователя, который выполнил вход, непосредственно в журнале аутентификации хоста. Общие учетные записи перестают быть анонимными. Выдавайте серийные номера с помощью -z, и каждый сертификат можно будет индивидуально идентифицировать позже — в списке отзыва или при поиске по логам.

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

Системы управления конфигурациями дают наилучшую запись об авторизации, но наихудшую — об аутентификации. Git точно показывает, кто предоставил доступ и когда. Сам же факт входа остается лишь именем учетной записи в journalctl -u ssh.

Все три метода зависят от выгрузки логов с сервера, так как пользователь root на хосте может редактировать локальные журналы. Аудиторский след, который хранится только на проверяемой машине, не является доказательством.

Стоимость развертывания каждого варианта

Развертывание OpenLDAP с нуля измеряется днями, к которым добавляется постоянное обслуживание: схемы, TLS-сертификаты, списки контроля доступа, репликация, резервное копирование каталога, настройка SSSD на каждом хосте и план управления SSH-ключами. FreeIPA развертывается за часы, если вы уже используете семейство RHEL и контролируете DNS, однако это решение избыточно для нескольких небольших VPS. Authentik с LDAP-провайдером обходится недорого, если вы уже используете Authentik для веб-приложений, но вопросы настройки SSSD, отказоустойчивости и прав sudo остаются на вашей стороне.

Настройка SSH CA занимает вторую половину дня для получения рабочей версии: создание ключа CA, добавление двух строк в sshd_config, создание файла principals для каждого хоста и написание скрипта подписи. Оставшаяся часть работы заключается в защите ключа CA и автоматизации выпуска сертификатов, чтобы не подписывать их вручную каждое утро. Именно для решения этой задачи существуют Vault и step-ca.

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

Что выбрать в зависимости от размера парка серверов

Если у вас менее 10 серверов и один-два администратора: используйте управление конфигурациями. В такой схеме нет централизованных точек отказа, git служит источником истины, а риск задержки отзыва доступа минимален, так как вы видите все свои хосты. На этом этапе внедрение службы каталогов создает единую точку отказа, которая с гораздо большей вероятностью заблокирует доступ вам самим, чем злоумышленнику удастся взломать систему. Включите первые десять минут настройки нового VPS в тот же playbook, чтобы каждый хост изначально был настроен единообразно.

От 10 до 50 серверов, несколько сотрудников, реальная текучесть кадров: используйте центр сертификации SSH (SSH CA). Отзыв доступа становится автоматическим, а не рутинным процессом; сертификаты хостов избавляют от запросов подтверждения отпечатков ключей; аудит действий каждого пользователя возможен даже при использовании общих учетных записей; при этом любой, у кого уже есть действующий сертификат, не пострадает в случае сбоя службы подписи. Продолжайте создавать локальные учетные записи через систему управления конфигурациями. Эти два подхода отлично дополняют друг друга.

Свыше этого количества, или когда одним и тем же людям нужна единая учетная запись для веб-приложений и для доступа по SSH, или когда процесс приема и увольнения сотрудников находится в ведении другого отдела: используйте службу каталогов. При таких масштабах операционные затраты оправданы, а риски сбоев управляемы, так как вы будете использовать реплики и заранее протестируете их работу. Выбирайте FreeIPA, если используете дистрибутивы семейства RHEL, или продукт SSO с поддержкой LDAP, если ваш веб-стек уже интегрирован с ним.

Одна комбинация заслуживает отдельного упоминания, так как именно она используется в крупных инфраструктурах. Служба каталогов управляет учетными записями, группами и правилами sudo. SSH CA отвечает за процесс входа и аудит. Они не заменяют друг друга. Независимо от выбранного решения, всегда сохраняйте локальную учетную запись для экстренного доступа (break-glass) и протестированный план действий на случай сбоя.

FAQ

Нужно ли использовать OpenLDAP для централизации входа в Linux?

Нет. OpenLDAP централизует идентификацию, но это лишь часть задачи. Если цель — «удалить пользователя один раз, чтобы доступ закрылся на всех серверах», то управление конфигурацией через authorized_keys и /etc/sudoers.d решает её для небольшого парка машин без зависимостей во время выполнения, а центр сертификации SSH обеспечивает это за счет автоматического истечения срока действия ключей. Каталог оправдывает затраты, когда у вас десятки хостов, частая ротация персонала или требование, чтобы учетные записи для входа в оболочку и веб-приложения были общими.

Что произойдет с входом в Linux, если LDAP-сервер выйдет из строя?

Хосты, использующие его для поиска пользователей, могут отклонять попытки входа или зависать, и поскольку все они обращаются к одному серверу, они откажут одновременно. Настройка cache_credentials = true позволяет пользователям, которые уже входили на этот хост, аутентифицироваться через локальный кэш, но у пользователя, который никогда не заходил на эту машину, или у хоста, созданного после начала сбоя, кэшированных данных не будет. Запустите второй сервер каталогов, настройте cache_credentials с разумным значением offline_credentials_expiration, сохраните на каждом хосте локальную учетную запись для экстренного доступа с собственным ключом и протестируйте всё это, заблокировав порт каталога на одной из машин.

Как немедленно отозвать SSH-доступ при использовании центра сертификации?

Обычный способ отзыва — истечение срока действия: подписывайте ключи с коротким интервалом, например -V +8h, и доступ прекратится сам собой. Для немедленного отзыва создайте список отозванных ключей с помощью ssh-keygen -k, распространите его на каждый хост и укажите на него в RevokedKeys внутри sshd_config. Это требует принудительной рассылки на все хосты, поэтому используйте данный метод как экстренный. Ни один из методов не завершает уже открытые сессии, поэтому при необходимости прерывайте их с помощью pkill -u alice.

Можно ли использовать Keycloak или Authentik для SSH-входа в Linux?

Authentik — да, Keycloak напрямую — нет. Аутентификация в Linux работает через NSS и PAM, которые взаимодействуют по протоколу LDAP, а не OIDC (OpenID Connect). Authentik поставляется с LDAP-провайдером, который предоставляет свою базу пользователей по протоколу LDAP и документирует SSSD в качестве клиента, поэтому хост Linux может подключиться к нему, как к любому другому каталогу. Keycloak выполняет федерацию из существующего LDAP-каталога, а не предоставляет его, поэтому он не устраняет необходимость в каталоге. Другой путь — использование центра сертификации SSH, который подписывает краткосрочный сертификат после входа через SSO; именно так работают step-ca и аналогичные продукты.