SSH-сертификаты OpenSSH: свой CA, выдача, ротация и отзыв доступа

Зачем переходить с authorized_keys на SSH-сертификаты

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

Полный цикл выглядит так: создание user CA и host CA, подпись клиентских ключей через ssh-keygen -s, настройка TrustedUserCAKeys на серверах, ограничения через principals и validity, ротация короткоживущих сертификатов, отзыв через KRL и миграция с authorized_keys без потери доступа. Всё необходимое уже есть в OpenSSH: сертификаты поддерживаются с версии 5.4, списки отзыва ключей KRL с версии 5.9, сторонние агенты и внешние сервисы не требуются. Версию удобно проверить командой ssh -V.

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

Проблемы классической модели authorized_keys

Парк из 200 серверов и 50 инженеров даёт до 10 000 строк в authorized_keys суммарно. Каждая строка это отдельный публичный ключ, который кто-то добавил вручную или через Ansible. Дальше начинаются предсказуемые сложности.

• Увольнение сотрудника. Нужно обойти все хосты и удалить его ключ. Часть хостов управляется конфиг-менеджером, часть настроена руками, часть поднята из старого снапшота, и ключ в ней остался.
• Отсутствие срока действия. Ключ с ноутбука, потерянного два года назад, продолжает работать, пока о нём кто-то не вспомнит.
• Нет разграничения по ролям. Один и тот же ключ даёт полный доступ везде, куда его добавили. Ограничение одной командой или одним пользователем приходится прописывать в authorized_keys для каждого ключа отдельно, и такие строки быстро теряются при правках.
• Аудит не отвечает на вопрос, кто именно подключался. В логах остаётся fingerprint ключа, а не человек и не выданная роль.
• Ручная раскладка ключей. Новый инженер ждёт, пока его ключ попадёт на 30 серверов, а новый сервер получает ключи предыдущего администратора.

Дополнительная проблема в том, что authorized_keys не имеет версионирования. Откатить ошибочно добавленный доступ можно только вручную и на каждом хосте отдельно.

Что даёт централизованный SSH CA

Схема с CA переносит все решения о доступе в один контролируемый узел и оставляет на серверах минимум информации.

• Единый корень доверия. В /etc/ssh/user_ca.pub лежит публичный ключ CA. Пока он там, сервер принимает любого владельца валидного сертификата.
• principals как ACL. Сертификат с principal deploy пускает только под пользователя deploy, а не под root.
• validity как TTL. Сертификат с +8h перестаёт действовать через восемь часов без чьего-либо участия.
• KRL как отзыв. Скомпрометированный ключ или уволенный сотрудник закрываются одним файлом, который расходится по серверам штатным способом.
• Хостовые сертификаты. HostCertificate убирает предупреждения known_hosts при пересоздании виртуальных машин из шаблона.

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

Создание пользовательского и хостового удостоверяющего центра

Разделяйте роли сразу. User CA подписывает клиентские ключи, host CA подписывает ключи серверов. Компрометация host CA позволяет выдать поддельный хостовый сертификат и организовать MITM, компрометация user CA даёт доступ ко всей инфраструктуре. Это разные риски, и хранить их в одном ключе нерационально.

Генерация ключей user CA и host CA

Для обоих CA подходит ed25519: короткая подпись, нет параметров, которые можно выбрать неправильно, и полная поддержка в OpenSSH. Команда ssh-keygen создаёт приватный и публичный файл сразу.

mkdir -p /root/ca && chmod 700 /root/ca

ssh-keygen -t ed25519 -f /root/ca/user_ca -C "user CA admin-wiki"
ssh-keygen -t ed25519 -f /root/ca/host_ca -C "host CA admin-wiki"

ssh-keygen спросит passphrase для приватного ключа. Задайте его интерактивно, а не через флаг -N: аргументы командной строки попадают в историю shell и в список процессов. Если нужна автоматизация без ввода пароля, используйте ssh-agent с ограниченным временем жизни ключа или аппаратный токен через PKCS#11.

Альтернатива для организаций с требованием RSA: ssh-keygen -t rsa -b 4096 -f /root/ca/user_ca. Работает так же, но подпись длиннее и медленнее проверяется при большом числе подключений.

Права на файлы после генерации:

chmod 600 /root/ca/user_ca /root/ca/host_ca
chmod 644 /root/ca/user_ca.pub /root/ca/host_ca.pub

Публичные ключи можно и нужно копировать на серверы и рабочие станции. Приватные не покидают хранилище CA ни в каком виде.

Безопасное хранение приватного ключа CA

Приватный ключ CA равносилен мастер-ключу от всей инфраструктуры: с ним можно подписать сертификат на любое имя пользователя и любой хост, не имея доступа к самим серверам. Требования к хранению жёсткие.

• Отдельный хост без production-нагрузки. Приватный ключ удобно держать на изолированном VDS вне основного контура, например на облачном сервере Timeweb Cloud, к которому нет доступа из интернета и нет лишних сервисов.
• Доступ только для root, никаких общих учётных записей и NFS-монтирований.
• Passphrase на приватном ключе и ssh-agent с ограниченным временем жизни. Для регулярных подписей агент поднимают на несколько минут вокруг вызова ssh-keygen.
• Резервная копия в зашифрованном виде на офлайн-носителе. Потеря приватного ключа CA означает невозможность выдать даже временный доступ, кроме заранее сохранённого аварийного ключа.
• Хранение вне git и вне бэкапов конфигураций Ansible, которые уходят на общие хранилища.

Если приватный ключ user CA скомпрометирован, считать доверие потерянным. Порядок действий: сгенерировать новый CA, заменить публичный ключ на всех серверах через конфиг-менеджер, отозвать старые сертификаты и раздать новые.

Подпись пользовательских ключей: principals, validity и ограничения

Подписывает сертификаты приватный ключ CA. Публичный ключ пользователя при этом не меняется: рядом с id_ed25519 появляется файл id_ed25519-cert.pub, который клиент отправляет серверу автоматически.

Синтаксис ssh-keygen -s и разбор флагов

ssh-keygen -s /root/ca/user_ca -I "ivanov-2026-09-11" -n ivanov -V +8h \
  -z 1042 ~/.ssh/id_ed25519.pub

На выходе получается ~/.ssh/id_ed25519-cert.pub, а исходный публичный ключ остаётся на месте. Разбор флагов, которые понадобятся в работе:

Без флага -V сертификат получается бессрочным. Это самая частая ошибка при первом знакомстве с механизмом: администратор проверяет вход, всё работает, и сертификат остаётся валидным навсегда, что возвращает исходную проблему authorized_keys в другом виде.

Ограничение прав через principals и validity

principal в сертификате проверяется при подключении. По умолчанию sshd требует, чтобы хотя бы один principal совпал с именем пользователя, под которым выполняется вход. Сертификат с -n deploy не откроет сессию под root, а сертификат с -n ivanov не подойдёт для пользователя deploy.

Гибкость добавляют два механизма sshd_config:

AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Если настроить этот файл, сервер принимает сертификат, у которого есть хотя бы один principal из списка. Это позволяет развести роли и логины: пользователь backup получает доступ по сертификату с principal backup-agent, а инженеры входят под своими именами. Есть и вариант с внешним источником: AuthorizedPrincipalsCommand подтягивает principals из LDAP или скрипта.

Срок действия задавайте по сценарию, а не одним значением на всех:

• Интерактивная работа инженера: -V +8h, максимум +12h.
• CI/CD: -V +5m или +15m, сертификат живёт ровно на время задачи.
• Ansible и автоматизация: -V +1h.
• Сервисный доступ с ограничением по команде: -V +24h и force-command.

Абсолютные интервалы удобны для подрядчиков и временных работ: -V 20260915:20260930. Даты указываются в формате YYYYMMDD.

Дополнительные ограничения: force-command, source-address, permit-*

Опции -O делятся на критичные и расширения. Критичные сервер обязан понимать: если sshd их не знает, сертификат отвергается целиком. Расширения игнорируются неизвестные. force-command и source-address относятся к критичным, поэтому старые версии OpenSSH могут отказать в подключении.

ssh-keygen -s /root/ca/user_ca -I "ci-deploy-runner" -n deploy -V +10m \
  -O no-pty -O no-port-forwarding -O no-agent-forwarding \
  -O no-X11-forwarding -O force-command="/usr/local/bin/deploy.sh" \
  -O source-address="10.20.0.0/16" deploy_ci.pub

Практические комбинации:

• Для CI: no-pty, no-port-forwarding, no-agent-forwarding, force-command на скрипт деплоя. Ограничение source-address привязывает сертификат к подсети раннеров.
• Для администратора: значения по умолчанию плюс короткий TTL. Ограничивать pty админу бессмысленно, он работает в интерактивной сессии.
• Для задач бэкапа: force-command на rsync или borg, no-pty, отдельный principal.

Учтите поведение по умолчанию: если не указать ни одной опции permit-*, sshd получит сертификат со всеми расширениями, включая проброс портов и агента. Любая указанная опция из группы permit-*/no-* сбрасывает набор по умолчанию, поэтому перечисляйте всё нужное явно.

Проверить результат до первого входа можно так:

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Настройка сервера: TrustedUserCAKeys и HostCertificate

Серверу нужно сказать, какому CA доверять и каким сертификатом представляться клиентам. Обе задачи решаются директивами в sshd_config.

Директивы TrustedUserCAKeys и HostCertificate в sshd_config

# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/user_ca.pub

HostKey /etc/ssh/ssh_host_ed25519_key
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

Файл user_ca.pub содержит один или несколько публичных ключей CA, по одному в строке. Директиву можно указать несколько раз с разными файлами: например, отдельный CA для инженеров, отдельный для подрядчиков и отдельный для CI. Это удобнее, чем один общий корень, потому что отзыв целого CA делается удалением строки из конфигурации.

install -m 644 -o root -g root /root/ca/user_ca.pub /etc/ssh/user_ca.pub

Файл должен принадлежать root и не быть доступным на запись группе или остальным. sshd строго проверяет права на этот файл и при слишком свободных правах откажется его читать, а вход по сертификатам просто перестанет работать. Ошибку видно в логах sshd при подключении.

Подпись хостового ключа и HostCertificate

Хостовый сертификат избавляет от ручного обновления known_hosts при пересоздании серверов. Ключ хоста подписывает host CA, флаг -h помечает сертификат как хостовый, а имя хоста передаётся через -n.

ssh-keygen -s /root/ca/host_ca -I host.example.com -h \
  -n host.example.com -V +52w \
  /etc/ssh/ssh_host_ed25519_key.pub

На выходе получается /etc/ssh/ssh_host_ed25519_key-cert.pub, который указывается в HostCertificate. Сертификат хоста обычно выдают на 52 недели: этого хватает, чтобы пересобрать шаблон виртуальной машины несколько раз без перевыпуска.

На стороне клиента доверие настраивается один раз в ssh_known_hosts или в ~/.ssh/known_hosts:

@cert-authority *.example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... host CA admin-wiki

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

Перезапуск sshd без потери доступа

Порядок применения конфигурации без риска закрыть себе доступ:

sshd -t
sshd -T | grep -i -E "trustedusercakeys|hostcertificate"
systemctl reload sshd

Команда sshd -t проверяет синтаксис и не применяет изменения. sshd -T печатает итоговую конфигурацию, это единственный надёжный способ убедиться, что директива реально подхватилась, а не перекрыта другим файлом из include. reload отправляет SIGHUP: sshd перечитывает конфиг, а уже установленные сессии не разрываются.

Держите открытой текущую root-сессию, пока проверяете вход из второго окна. Отключать PasswordAuthentication и удалять старые authorized_keys на этом этапе нельзя.

Ротация сертификатов без пересборки конфигурации на серверах

Ротация в схеме с CA означает перевыпуск сертификата на стороне клиента или CA. Серверы в процессе не участвуют, потому что знают только публичный ключ CA. Это ключевое отличие от authorized_keys, где смена ключа требовала обхода хостов.

Короткий TTL как основа ротации

Чем короче срок действия, тем меньше окно риска при утере ноутбука или ключа. Ограничение одно: TTL должен быть больше интервала между перевыпусками, иначе вы получите отказы в доступе в самый неподходящий момент.

Ориентир: перевыпуск делайте не позже, чем за треть срока до истечения. Для TTL в 8 часов это значит обновление каждые 5 часов, а не в последний момент.

Автоматизация перевыпуска через cron и systemd timer

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

#!/bin/bash
set -euo pipefail
CA=/root/ca/user_ca
KEY="$HOME/.ssh/id_ed25519"
USER_NAME="$(whoami)"

ssh-keygen -s "$CA" \
  -I "$USER_NAME-$(date +%Y%m%d%H%M)" \
  -n "$USER_NAME" \
  -V +8h \
  "$KEY.pub"

ssh-add -d "$KEY" >/dev/null 2>&1 || true
ssh-add "$KEY"

Файл сертификата ssh-keygen создаёт сам и кладёт рядом с ключом как id_ed25519-cert.pub. После перевыпуска ключ нужно перезагрузить в ssh-agent: ssh-add подхватывает сертификат, если он лежит рядом с приватным ключом.

Расписание на systemd выглядит так:

# /etc/systemd/system/ssh-cert-renew.service
[Unit]
Description=Renew SSH user certificate

[Service]
Type=oneshot
User=ivanov
ExecStart=/usr/local/bin/renew-ssh-cert.sh

# /etc/systemd/system/ssh-cert-renew.timer
[Unit]
Description=Renew SSH certificate every 5 hours

[Timer]
OnCalendar=*-*-* 06,11,16,21:00:00
Persistent=true
RandomDelaySec=300

[Install]
WantedBy=timers.target

Включение таймера: systemctl enable --now ssh-cert-renew.timer. Проверка: systemctl list-timers ssh-cert-renew.timer. Случайная задержка RandomDelaySec разносит нагрузку, если таких таймеров в компании сотни.

Не делайте TTL короче интервала перевыпуска. Ошибка в таймере или недоступный CA-хост превращаются в полную потерю доступа для всех, кто не имеет резервного ключа.

Отзыв доступа через KRL без правки конфигов на серверах

Отзыв в схеме с сертификатами выполняется через KRL (Key Revocation List), бинарный файл со списком отозванных ключей и сертификатов. Файл формируется на стороне CA и раскладывается на серверы штатным способом: через Ansible, pull по cron из внутреннего репозитория или средствами конфиг-менеджера.

Создание и обновление KRL

# создать пустой файл отзыва
ssh-keygen -k -f /root/ca/revoked_keys

# отозвать конкретный публичный ключ по файлу ключа
ssh-keygen -k -u -f /root/ca/revoked_keys /home/ivanov/.ssh/id_ed25519.pub

# отозвать сертификаты по серийным номерам
ssh-keygen -k -u -f /root/ca/revoked_keys -s /root/ca/user_ca.pub serials.txt

Флаг -k создаёт или обновляет список отзыва, -u добавляет записи к существующим. Файл serials.txt содержит по одному серийному номеру сертификата в строке. Флаг -s с публичным ключом CA нужен, чтобы ssh-keygen проверил подпись отзываемых сертификатов и не дал внести в список произвольные номера. Флаг -z задаёт версию KRL, по ней удобно проверять, доехало ли обновление до сервера.

# посмотреть содержимое KRL
ssh-keygen -l -f /root/ca/revoked_keys

# посмотреть серийный номер конкретного сертификата
ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub | grep -i serial

Директива RevokedKeys и распространение KRL

# /etc/ssh/sshd_config
RevokedKeys /etc/ssh/revoked_keys

Вариантов доставки файла три: push через Ansible, pull по расписанию с внутреннего HTTP-эндпоинта или раскладка через конфиг-менеджер. Разница только в скорости, с которой отзыв вступит в силу. В Ansible достаточно задачи copy и handler на reload sshd.

# проверка, что файл доехал и совпадает по контрольной сумме
sha256sum /etc/ssh/revoked_keys
systemctl reload sshd

Серийный номер в сертификате задаётся при подписи через -z, и его стоит выдавать централизованно: например, монотонно растущий счётчик в базе CA. Тогда отзыв уволенного сотрудника сводится к добавлению одного числа в serials.txt, без поиска файлов его ключей по рабочим станциям.

Отзыв пользователя в LDAP, FreeIPA или AD на SSH-сертификаты не влияет: сертификат проверяется криптографически, а не по наличию учётной записи в каталоге. Удаление пользователя из каталога закроет вход по паролю или по key-based доступу через централизованную аутентификацию, но подписанный сертификат продолжит работать до истечения TTL.

Проверка, диагностика и типовые ошибки

Отладка доступа по сертификатам быстрее идёт от содержимого сертификата к конфигу сервера, а не наоборот.

Чтение сертификата и проверка полей

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

Вывод показывает тип сертификата, публичный ключ, ключ CA, которым выполнена подпись, Key ID, Serial, интервал Valid, список Principals, Critical Options и Extensions. Первое, что нужно сверить: совпадает ли principal с именем пользователя, на которое вы подключаетесь, и покрывает ли интервал Valid текущее время на сервере.

# что сервер видит в своей конфигурации
sshd -T | grep -i -E "trustedusercakeys|revokedkeys|hostcertificate"

# подробный лог подключения со стороны клиента
ssh -vvv ivanov@host 2>&1 | grep -i -E "cert|principal|offering|accept"

# логи сервера
journalctl -u ssh -e
journalctl -u sshd -e

В выводе ssh -vvv ищите строки Certificate invalid с причиной: name is not a listed principal, expired, not yet valid, revoked. Эти формулировки прямо указывают на проблему. Если сертификат вообще не упоминается в логе, клиент его не нашёл и предлагает обычный ключ. Смежная тема, ошибки TLS-сертификатов в nginx, Apache и API, разобрана в статье про диагностику SSL/TLS-сертификатов: логика проверки цепочки и сроков там похожа, хотя инструменты другие.

Типовые ошибки и их причины

Отдельный случай на стороне рабочих станций Windows: VS Code Remote-SSH при поиске ssh-клиента может взять ssh из Git for Windows, даже если OpenSSH установлен и доступен в PATH. В такой конфигурации ломается ProxyJump, и подключение через промежуточный хост работает не так, как в терминале. Проверьте, какой именно ssh используется в расширении, и при необходимости укажите путь к системному ssh явно.

Пошаговый план миграции с authorized_keys на SSH-сертификаты

Главный риск перехода не технический, а операционный: можно закрыть доступ себе и всей команде. План ниже рассчитан на то, что старый способ входа остаётся рабочим до последнего этапа.

Пилот на одном сервере

1. Создать user CA и host CA, сохранить приватные ключи на выделенном хосте, скопировать user_ca.pub на тестовый сервер.
2. Подписать свой рабочий ключ: ssh-keygen -s /root/ca/user_ca -I "pilot-ivanov" -n ivanov -V +8h ~/.ssh/id_ed25519.pub.
3. Добавить на тестовом сервере директиву TrustedUserCAKeys, не трогая PasswordAuthentication и authorized_keys.
4. Проверить конфиг через sshd -t, применить через systemctl reload sshd, войти в новой сессии.
5. Посмотреть лог: в нём должно быть указано, что вход выполнен по сертификату, а не по обычному ключу.

Полезный приём: поднять тестовый sshd на отдельном порту с альтернативным конфигом и проверить сертификаты на нём, вообще не касаясь рабочего процесса.

sshd -f /etc/ssh/sshd_config_test -p 2222 -D -e

Резервный доступ и rollback

На время миграции оставьте два пути восстановления: аварийный ssh-ключ или пароль для отдельной учётной записи и копию прежнего authorized_keys. Вторая сессия должна быть открыта на каждом шаге, потому что reload и правки конфигурации могут совпасть с неожиданной проблемой.

План отката простой и должен быть записан заранее:

1. Войти по резервному доступу.
2. Закомментировать TrustedUserCAKeys и RevokedKeys в sshd_config.
3. Проверить конфиг через sshd -t и выполнить systemctl reload sshd.
4. Убедиться, что вход по обычным ключам работает.

Отключать password-аутентификацию и удалять authorized_keys можно только после того, как сертификаты проверены на всей группе серверов, а мониторинг подтверждает, что вход по сертификату проходит у всех сотрудников.

Чек-лист миграции

• user CA и host CA созданы, приватные ключи хранятся на изолированном хосте с правами 600.
• Публичный ключ user CA скопирован в /etc/ssh/user_ca.pub на серверах, права 644, владелец root.
• Директива TrustedUserCAKeys добавлена и видна в выводе sshd -T.
• Тестовый вход по сертификату выполнен, причина отказа при ошибке видна в ssh -vvv.
• Хостовые ключи подписаны, HostCertificate указан, @cert-authority добавлен в known_hosts на клиентах.
• KRL создан, RevokedKeys настроен, доставка файла на серверы автоматизирована и контролируется.
• Таймер или cron перевыпускает сертификаты с запасом по времени.
• Резервный доступ сохранён и проверен, план отката записан.
• authorized_keys и парольный вход отключены только после успешной проверки на всех группах серверов.

После перехода стоит пересмотреть общий периметр: аудит учётных записей, обновлений и сетевых служб удобно делать по чек-листу аудита безопасности Linux-серверов, а проверку отдельно взятых хостов и SSH-настроек можно сверить с чек-листом по пользователям, SSH и службам. SSH-сертификаты закрывают одну крупную дыру в управлении доступом, но не заменяют регулярную ревизию привилегий и обновлений.