В инфраструктуре из 1000 серверов и 100 администраторов счет активным SSH-ключам может идти на тысячи. По умолчанию они не имеют срока действия, поэтому со временем накапливаются и устаревают.
Исследования показывают, что в крупных компаниях до 90% ключей не используются и не администрируются, а часть оставшихся предоставляет доступ на уровне root. Отсутствие централизованного управления усугубляет проблему: при увольнении сотрудника его доступы могут забыть удалить, сохранив за ним возможность подключаться к системам.
В итоге администраторы оказываются перед трудоемкой задачей контроля и актуализации авторизационных данных.
Файл authorized_keys: принцип работы и ограничения
Сначала рассмотрим один из самых распространенных способов аутентификации — по открытому ключу — PKA, Public Key Authentication. Он стал популярен благодаря сочетанию простоты, высокой криптографической стойкости и отсутствия необходимости передавать пароли по сети.
В современных системах стандартом реализации признан программный пакет OpenSSH. По умолчанию он аутентифицирует пользователя по публичному ключу, который должен находиться в файле ~/.ssh/authorized_keys на целевом сервере. Каждая строка содержит один ключ с опциями доступа. При попытке соединения SSH-демон sshd сверяет предъявленные клиентом данные с сохраненными записями и в случае совпадения разрешает вход.
Основная сложность эксплуатации — в контроле. При большом количестве пользователей добавлять и отзывать их права приходится вручную. Смена ключей требует редактирования authorized_keys на каждой машине — процесс крайне трудоемкий процесс и подверженный человеческим ошибкам.
Немного упростить задачу помогает параметр expiry-time, позволяющий ограничить время жизни ключа. Чтобы задать точную дату деактивации, используется запись вида:
expiry-time=”20261231″ ssh-ed25519 AAAAZenZeN0ttIIN1NTENAAAAI… geralt@pc
Однако проблему синхронизации и управления это не решает. Полный запрет доступа зачастую сводится к физическому затиранию нужной строк из authorized_keys на всех серверах.
Для экономии времени на управление ключами в OpenSSH есть механизм AuthorizedKeysCommand. Этот параметр конфигурационного файла sshd_config задает команду, которая динамически возвращает список разрешенных ключей вместо чтения статического файла. Сервер запрашивает информацию из внешнего источника — чаще всего из базы данных, где расположены открытые ключи. При таком подходе администратору достаточно удалить или заблокировать ключ в центральном хранилище — и он сразу перестает работать на всех узлах инфраструктуры.
Альтернативные подходы к управлению доступом
LDAP
LDAP (Lightweight Directory Access Protocol, облегченный протокол доступа к каталогам) — централизованный метод контроля, позволяющий хранить пароли, ключи и учетные записи в единой базе данных.
Управление осуществляется через LDAP-каталог, где данные можно добавлять, изменять или удалять в одном месте. При этом актуальная информация сразу становится доступна всем SSH-серверам. Отзыв прав происходит через редактирование или удаление нужной записи в каталоге, после чего обновления автоматически применяются ко всем системам.
Бастионные хосты
В LDAP ключи хранятся статически, и при их большом количестве регулярные опросы каталога создают повышенную нагрузку на инфраструктуру. Альтернативой такому подходу выступает бастион-хост — выделенный сервер в периметре сети, через который маршрутизируется весь входящий SSH-доступ в сеть внутреннюю.
Пользователи подключаются к нему по заранее одобренным ключам, а уже оттуда переходят к остальным серверам. Надежность этой схемы обеспечивается параметром from=. Он прописывается на конечных узлах и ограничивает разрешенные IP-адреса и имена пользователей, полностью исключая возможность подключения в обход бастиона.
from="192.168.100.1,10.1.1.0/24" ssh-ed25519 AAAAZenZeN0ttIIN1NTENAAAAI... geralt@pc
Такая архитектура повышает контроль и безопасность, но лишь смещает фокус управления: теперь ключи нужно хранить и администрировать на бастионе. Сервер становится единой точкой отказа, поэтому его компрометация критична для всей сети. Кроме того, использование промежуточного хоста не избавляет от необходимости масштабного управления доступами.
К важным недостаткам такого подхода относятся высокая ответственность администратора за единственный шлюз и полная недоступность внутренних узлов при сбоях. Однако главное — необходимость управлять ключами для входа на сам бастион, что по сути возвращает к исходной проблеме.
PAM
Развитие облачных технологий привело к появлению новых подходов к управлению ключами — решения класса PAM (Privileged Access Management, управление привилегированным доступом) и Zero Trust Access (доступ по модели нулевого доверия).
Распространенные решения — Teleport, Boundary, Delinea или CyberArk. Они объединяют в себе централизованное хранилище, веб-интерфейс и инструменты аудита сеансов. Подобные системы позволяют отказаться от постоянных SSH-ключей. Вместо их ручного распределения пользователю автоматически выдается краткосрочный сессионный сертификат после аутентификации через SSO.
В результате администраторы получают единый портал управления и могут в любой момент отозвать права доступа через отмену сертификации. Применение связки из PAM и SSO существенно упрощает масштабное администрирование, но требует серьезной интеграции с существующей инфраструктурой.
SSH CA: принципы работы сертификатов
PKI (Public Key Infrastructure, инфраструктура открытых ключей) — это система управления цифровыми сертификатами, которая обеспечивает проверку подлинности участников на основе доверия единому центру сертификации.
В SSH эта модель адаптирована путем подписания идентификаторов пользователей и хостов доверенным Центром Сертификации. Новый подход появился из-за сложностей масштабирования: SSH CA (Certificate Authority) позволяет заменить хранение тысяч ключей на серверах более удобным вариантом — централизованным контролем и отзывом прав по истечении срока действия.
В OpenSSH сертификатом называется публичный ключ, подписанный приватным ключом CA и снабженный метаданными – списком разрешенных имен пользователей или хостов. На стороне сервера или клиента в конфигурации прописывается доверие к открытым ключам CA.
Проверка хостов выполняется следующим образом: публичный ключ CA вносится в файл known_hosts с маркером @cert-authority или через ssh_config.
OpenSSH поддерживает два типа сертификатов: пользовательские и хостовые. Первый аутентифицирует пользователя на сервере, в нем указываются допустимые логины.
При использовании второго сервер предъявляет хостовый сертификат клиенту, чтобы подтвердить свою подлинность и гарантировать защиту подключения от перехвата.
Основная идея в обоих случаях — сервер и клиент доверяют не списку конкретных ключей, а ключу CA и подписи сертификата. При соединении они обмениваются сертификатами и проверяют, что подпись выполнена доверенным CA, а сам документ еще не просрочен.
Главное преимущество сертификатов — в централизованном контроле и ограничении времени жизни. В метаданных можно явно задать срок действия, что автоматически делает ключ временным.
Развертывание SSH CA: практика и примеры
Для развертывания собственного центра сертификации, необходимо сгенерировать пару ключей CA — для подписи пользовательских и хостовых сертификатов:
ssh-keygen -t ed25519 -f ~/.ssh/ca_user
Флаг -t отвечает за тип алгоритма шифрования, а -f задает путь файла и его имя.
Закрытый ключ ca_user остается на сервере автоматизации (или машине администратора), а открытый ca_user.pub копируется на целевые серверы в каталог /etc/ssh/ca_user.pub.
Затем в конфигурационном файле сервера /etc/ssh/sshd_config прописывается директива:
TrustedUserCAKeys /etc/ssh/ca_user.pub
После этого сервер начнет доверять всем ключам, подписанным данным центром сертификации. Чтобы изменения вступили в силу, необходимо перезапустить службу SSH:
sudo systemctl restart ssh
Выдача доступа происходит, когда пользователь предоставляет свой публичный ключ, который подписывается закрытым ключом CA:
ssh-keygen -s ca_key -I root -n root id_ed25519.pub
Флаг -s указывает путь к ключу CA, -I задает внутренний идентификатор сертификата (Key ID для логирования), а -n определяет список разрешенных учетных записей (системных логинов).
В результате создается файл сертификата id_ed25519-cert.pub. Пользователю достаточно разместить его в одной директории со своим приватным ключом — OpenSSH автоматически обнаружит и применит сертификат при подключении.
После настройки доверия к CA администрирование сводится исключительно к выпуску и отзыву сертификатов, избавляя от необходимости вручную распространять ключи пользователей по серверам. Использование надежной криптографии также позволяет полностью отказаться от паролей, что существенно повышает общий уровень безопасности инфраструктуры.
Жизненный цикл SSH-сертификатов
Сертификаты имеют строго ограниченный жизненный цикл. При их создании через утилиту ssh-keygen можно задать период валидности с помощью флага -V [начало_действия]:[конец_действия]. По истечении этого срока сертификат становится недействительным, что позволяет автоматически отзывать доступ без ручного вмешательства.
Для случая, когда сертификат нужно отозвать досрочно, OpenSSH поддерживает списки отозванных ключей (KRL, Key Revocation List). Сформировать такой перечень на CA-сервере можно командой:
ssh-keygen -k -f /etc/ssh/ca_revoked_keys
Добавить идентификатор отзываемого сертификата в существующий список можно с помощью флагов -k и -u:
ssh-keygen -k -u -f /etc/ssh/ca_revoked_keys compromised-cert.pub
Здесь -f задает путь к обновляемому файлу списка, а compromised-cert.pub — отзываемый сертификат или публичный ключ.
Однако на практике чаще применяются короткоживущие сертификаты со сроком действия от нескольких часов до суток. В таком сценарии права истекают быстро и предсказуемо, что существенно снижает потребность в использовании механизмов принудительного отзыва.
Для непрерывной работы новые сертификаты периодически запрашиваются пользователем по API или через системы управления доступом, упомянутые ранее. При этом центр сертификации выступает единой точкой контроля, отслеживая и протоколируя каждый факт выпуска ключей.
Сравнение подходов: authorized_keys против SSH CA
authorized_keys – актуален, но плохо масштабируется
Использование файла authorized_keys остается базовым механизмом аутентификации. Однако в крупных инфраструктурах такой подход плохо масштабируется. Главная сложность — в децентрализации. Публичные ключи администраторов приходится хранить локально на каждом целевом узле.
Поскольку они не имеют встроенного срока действия, доступ остается открытым вплоть до ручного удаления. В итоге обновление или отзыв прав превращается в трудоемкий многошаговый процесс, требующий редактирования authorized_keys на всех серверах.
При таких объемах рутинной работы человеческий фактор неизбежен: опечатки, дублирование записей, забытые при увольнениях доступы — все это многократно повышают риск скопления неучтенных ключей.
SSH-сертификаты (CA) – современный и масштабируемый подход.
Сертификаты можно делать короткоживущими с автоматическим истечением срока действия. При этом системе достаточно доверять единому центру сертификации (CA) и проверять его подпись, вместо того чтобы хранить сотни статических ключей.
Такой подход обеспечивает централизованный контроль и гибкость, однако требует развертывания отдельной инфраструктуры CA. Ее надежная защита критически важна: компрометация центра позволит злоумышленникам выпускать поддельные сертификаты от имени любых пользователей.
Кроме того, внедрение новой модели потребует обучения команды, поскольку каждый сотрудник должен уметь самостоятельно получать и отзывать свои доступы.
Так как же защищать CA? Вот краткий чеклист:
- Приватный ключ CA хранится на защищенной, изолированной машине.
- Доступ к подписанию сертификатов ограничен через аутентификацию.
- Журналирование всех операций включено.
- Есть разделение ролей.
- Настроена автоматическая ротация ключей CA, создаются бэкапы.
Выбор между authorized_keys и SSH CA зависит от масштаба инфраструктуры. Для небольшого парка серверов и малого числа пользователей традиционная схема с authorized_keys остается простой и понятной. Однако по мере расширения сети затраты на сопровождение ключей, аудит доступов и отзыв прав возрастают непропорционально количеству систем.
Развертывание SSH CA требует дополнительных организационных мер и защиты центра сертификации. Взамен этот подход обеспечивает централизованное управление доступом, поддержку короткоживущих учетных данных и более высокий уровень автоматизации.
Заключение
Развитие инфраструктуры ставит компанию перед выбором: использовать сложномасштабируемый механизм authorized_keys или внедрять более удобный SSH CA.
При росте числа сотрудников первый путь неизбежно приводит к накоплению забытых ключей, усложняет аудит и повышает риск ошибок управления доступом.
Второй подход заменяет работу с разрозненными файлами на централизованное администрирование через единый центр сертификации. Это обеспечивает контролируемый жизненный цикл учетных записей и позволяет своевременно отзывать выданные права.
