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

SSH-сертификаты OpenSSH позволяют заменить разрозненные записи в authorized_keys управляемой схемой с короткоживущими удостоверениями. Пользовательский открытый ключ подписывает доверенный CA, сервер принимает публичный ключ этого CA через TrustedUserCAKeys, а доступ ограничивается principal, сроком действия и дополнительными параметрами.

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

В статье показаны создание собственного CA на базе Ed25519, настройка sshd_config, выпуск сертификатов через ssh-keygen -s, отзыв с помощью KRL и план миграции без потери доступа. Примеры ориентированы на Linux-серверы с OpenSSH. Названия службы и пути к журналам могут отличаться в Debian, Ubuntu, RHEL и производных системах.

SSH-сертификаты OpenSSH: что меняется в модели доступа

Сертификат OpenSSH и обычный публичный ключ

При классической схеме сервер хранит публичные ключи пользователей в файле ~/.ssh/authorized_keys. Чтобы выдать доступ новому сотруднику, администратор добавляет строку на каждый сервер. При увольнении или смене роли записи приходится искать и удалять вручную.

SSH-сертификат OpenSSH переносит доверие на центр сертификации. Сервер доверяет CA, а CA подписывает открытый ключ пользователя с указанием:

• идентификатора выпуска, поля key ID;
• серийного номера сертификата;
• одного или нескольких principals;
• времени начала и окончания действия;
• critical options и extensions.

Такая модель сокращает число долгоживущих настроек на серверах. Доступ можно выдавать на 8 часов, 24 часа или другой срок, соответствующий риску. После окончания срока сертификат перестает проходить проверку без изменения authorized_keys.

SSH-сертификаты OpenSSH не относятся к TLS-сертификатам. Они используются внутри протокола SSH и не требуют публичной PKI, доменного имени или сертификата от внешнего центра сертификации.

Когда собственный CA оправдан, а когда достаточно authorized_keys

Собственный CA оправдан, когда в инфраструктуре есть десятки серверов, несколько команд доступа, частая смена сотрудников, временные полномочия или автоматическая выдача сертификатов. Схема особенно полезна для bastion-хостов, CI/CD и доступа через ProxyJump, где ручная синхронизация ключей быстро становится источником ошибок.

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

• закрытый ключ CA нужно хранить отдельно и защищать сильнее обычных пользовательских ключей;
• каждому сертификату нужен серийный номер и запись о владельце;
• для отзыва требуется распространять KRL на серверы;
• часы на клиентах и серверах должны быть синхронизированы;
• нужны резервный канал доступа и процедура выпуска нового CA.

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

Как устроена схема SSH CA в OpenSSH

Роли CA, пользовательского ключа и сертификата

В схеме участвуют три разных объекта:

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

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

Как сервер сопоставляет principal с Unix-пользователем

Principal описывает имя или роль, разрешенную сертификату. Валидная подпись CA недостаточна: sshd должен найти principal в разрешенном для учетной записи источнике.

Простейший вариант, principal совпадает с именем Unix-пользователя. Для пользователя deploy сертификат выпускают с principal deploy. При ролевой модели сертификат может содержать ops, deploy или breakglass, а сервер сопоставляет эти значения с файлом AuthorizedPrincipalsFile.

Например, для пользователя alice файл /etc/ssh/auth_principals/alice может содержать:

ops
readonly

В этом случае сертификат Alice пройдет проверку для Unix-учетной записи только при наличии principal ops или readonly. Ролевые principals позволяют отделить имя человека от набора полномочий. Не следует разрешать любой principal без явного контроля файла или команды, которая его формирует.

Создание и защита собственного CA для SSH OpenSSH

Генерация ключей CA и проверка отпечатка

Создайте отдельную рабочую директорию на защищенной машине, которая не используется как обычный SSH-сервер:

umask 077
mkdir -p ~/ssh-ca
chmod 700 ~/ssh-ca
cd ~/ssh-ca
ssh-keygen -t ed25519 -f user_ca -C "OpenSSH user CA"

Команда создаст закрытый ключ user_ca и публичный ключ user_ca.pub. Для закрытого ключа задайте длинную passphrase. Проверить тип и отпечаток можно так:

ssh-keygen -lf user_ca.pub
ls -l user_ca user_ca.pub

Ожидаемые права: закрытый ключ доступен только владельцу, публичный ключ может читаться процессом sshd:

chmod 600 user_ca
chmod 644 user_ca.pub

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

Операционная защита закрытого ключа CA

Закрытый ключ CA храните в офлайн-среде или в отдельном сервисе, который разрешает подпись только уполномоченным операторам. Серверы должны получать только файл user_ca.pub.

Минимальный набор мер:

• ограничьте круг пользователей, которые могут подписывать сертификаты;
• зашифруйте резервную копию закрытого ключа и храните ее отдельно от основной копии;
• журналируйте владельца ключа, principal, serial, TTL и причину выдачи;
• разделите CA для production, staging и аварийного доступа;
• проверяйте целостность рабочей станции, где выполняется подпись;
• не передавайте закрытый ключ CA через почту, чаты или обычные файловые хранилища.

Для критичной инфраструктуры полезно разделить права запроса и подписи. Пользователь или система автоматизации передает оператору публичный ключ и метаданные, а оператор проверяет запрос и выполняет подпись. Закрытый ключ пользователя при этом не покидает рабочую станцию.

Настройка TrustedUserCAKeys и principals на сервере

Базовая конфигурация TrustedUserCAKeys

Скопируйте публичный ключ CA на тестовый сервер:

sudo install -o root -g root -m 0644 user_ca.pub /etc/ssh/user_ca.pub

В /etc/ssh/sshd_config добавьте:

TrustedUserCAKeys /etc/ssh/user_ca.pub

Директива задает доверенный источник подписей для пользовательских сертификатов. Она не перечисляет пользователей и не разрешает вход без сертификата. Путь должен указывать на публичный ключ CA, а файл должен быть доступен процессу sshd.

AuthorizedPrincipalsFile для явного контроля ролей

Создайте каталог для principal-файлов:

sudo install -d -o root -g root -m 0755 /etc/ssh/auth_principals
sudo install -o root -g root -m 0644 /dev/null /etc/ssh/auth_principals/alice

Добавьте разрешенные роли:

sudo sh -c 'printf "%s\n" ops readonly > /etc/ssh/auth_principals/alice'

В конфигурации укажите шаблон:

AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u

Маркер %u заменяется именем Unix-пользователя. Для простого сценария можно выпускать сертификаты с principal, совпадающим с именем учетной записи, и использовать отдельный файл для каждого пользователя. При ролевой модели один пользователь получает только те principals, которые нужны его задачам.

Проверка и безопасное применение sshd_config

Не закрывайте действующую административную сессию до проверки нового входа. Сначала проверьте синтаксис:

sudo sshd -t

Посмотрите эффективные параметры:

sudo sshd -T | grep -E 'trustedusercakeys|authorizedprincipalsfile|revokedkeys'

Примените конфигурацию без остановки службы:

sudo systemctl reload sshd

В Debian и Ubuntu имя службы обычно ssh, поэтому при необходимости используйте:

sudo systemctl reload ssh

Откройте отдельную новую сессию и проверьте вход сертификатом. Действующее подключение оставьте открытым до успешной проверки sudo, перехода на нужные серверы и аварийного доступа через консоль или out-of-band канал.

Выпуск пользовательских SSH-сертификатов OpenSSH

Подготовка ключа пользователя и запрос на выдачу

Пользователь создает ключевую пару на рабочей станции:

umask 077
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "alice@workstation"

Закрытый ключ защищают passphrase и не передают оператору CA. Для выдачи достаточно передать файл id_ed25519.pub и запрос с именем пользователя, окружением, principal, сроком действия и назначением доступа.

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

Подписание сертификата через ssh-keygen -s

Базовый шаблон выпуска выглядит так:

ssh-keygen -s user_ca \
  -I alice-prod-2026-08-28 \
  -n ops \
  -V +8h \
  -z 1001 \
  id_ed25519.pub

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

• -s user_ca, закрытый ключ CA, которым выполняется подпись;
• -I, key ID, текстовый идентификатор выпуска для аудита;
• -n ops, список principals, разрешенных сертификату;
• -V +8h, период действия, здесь 8 часов с момента выпуска;
• -z 1001, уникальный серийный номер сертификата.

Для выпуска на фиксированный интервал используйте формат с датой и временем, например 20260828090000:20260828170000. Часовой пояс и формат времени нужно согласовать с используемой версией OpenSSH. На практике короткий TTL снижает окно злоупотребления украденным сертификатом, но требует автоматизированной выдачи или понятного ручного процесса.

Ограничения сертификата: extensions и critical options

Расширения задают доступные возможности сессии. Для интерактивного доступа часто оставляют pty и отключают лишние типы forwarding. Например:

ssh-keygen -s user_ca \
  -I alice-prod-2026-08-28 \
  -n ops \
  -V +8h \
  -z 1002 \
  -O clear \
  -O permit-pty \
  -O no-agent-forwarding \
  -O no-port-forwarding \
  -O no-X11-forwarding \
  id_ed25519.pub

Набор параметров зависит от версии OpenSSH и политики среды. Для CI/CD обычно не нужен интерактивный терминал, а для аварийной учетной записи могут потребоваться отдельные ограничения, например force-command или source-address.

• permit-pty разрешает псевдотерминал;
• permit-agent-forwarding разрешает пересылку SSH-агента;
• permit-port-forwarding разрешает туннели;
• permit-X11-forwarding разрешает X11-пересылку;
• source-address ограничивает исходные IP-адреса;
• force-command принудительно задает команду при входе.

Выдавайте минимальный набор возможностей. Агентную пересылку и произвольные туннели не следует включать для автоматизаций без конкретной потребности.

Проверка сертификата до передачи пользователю

Проверьте содержимое сертификата:

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

В выводе должны совпадать тип сертификата ssh-ed25519-cert-v01@openssh.com, key ID, serial, principals, valid-after, valid-before, critical options и extensions. Особое внимание уделите principal ops и времени окончания действия.

Проверочное подключение выполняйте явно:

ssh \
  -o IdentityFile=~/.ssh/id_ed25519 \
  -o CertificateFile=~/.ssh/id_ed25519-cert.pub \
  alice@server.example

В рабочей конфигурации OpenSSH обычно автоматически подхватывает файл с суффиксом -cert.pub, если рядом найден соответствующий закрытый ключ. При сомнениях используйте ssh -vvv и проверьте, какой ключ и сертификат отправляет клиент.

Отзыв сертификатов через KRL

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

KRL, Key Revocation List, это локальная база отозванных ключей и сертификатов OpenSSH. Она позволяет заблокировать доступ до естественного окончания TTL.

Сохраните отозванный сертификат в отдельном каталоге и создайте KRL:

mkdir -p ~/ssh-ca/revocations
chmod 700 ~/ssh-ca/revocations
ssh-keygen -k -f ~/ssh-ca/revoked.krl \
  ~/ssh-ca/revocations/alice-prod-cert.pub

При отзыве фиксируйте serial, key ID, владельца, причину, время и оператора. Для больших сред исходные сертификаты и журнал выпуска нужно хранить так, чтобы повторно проверить основание отзыва.

Существующий KRL обновляют повторным вызовом с параметром -u:

ssh-keygen -k -u -f ~/ssh-ca/revoked.krl \
  ~/ssh-ca/revocations/alice-prod-cert.pub

Формат входных данных и доступные варианты отзыва зависят от версии OpenSSH. Перед массовым обновлением проверьте команду на тестовой копии KRL.

Подключение RevokedKeys в sshd

Скопируйте KRL на сервер и добавьте в /etc/ssh/sshd_config:

sudo install -o root -g root -m 0644 revoked.krl /etc/ssh/revoked.krl

RevokedKeys /etc/ssh/revoked.krl

После обновления выполните:

sudo sshd -t
sudo systemctl reload sshd

Распространяйте KRL на все серверы, где отзыв должен действовать. Если обновился только один узел, скомпрометированный сертификат продолжит работать на остальных.

Проверка отзыва и действия при компрометации CA

Локально проверьте сертификат по KRL:

ssh-keygen -Q -f revoked.krl id_ed25519-cert.pub

Затем создайте новую SSH-сессию. Проверяйте журнал службы:

sudo journalctl -u sshd --since "10 minutes ago"
sudo journalctl -u ssh --since "10 minutes ago"

В системах с отдельным файлом аутентификации дополнительно проверяйте /var/log/auth.log или /var/log/secure. Название файла зависит от настроек journald и syslog.

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

Поэтапная миграция с authorized_keys без потери доступа

Инвентаризация доступа и резервный канал

Перед изменениями соберите таблицу доступа:

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

Пилот: параллельная работа authorized_keys и сертификатов

Начните с тестового сервера. Добавьте TrustedUserCAKeys и AuthorizedPrincipalsFile, но не удаляйте действующие строки из authorized_keys. Выпустите сертификаты для одной или двух учетных записей.

Проверьте:

• интерактивный вход и работу sudo;
• подключение через bastion и ProxyJump;
• запуск Ansible;
• доступ Git и работу CI/CD;
• истечение сертификата после заданного TTL;
• отзыв через KRL;
• поведение при неправильном principal;
• вход по старому ключу во время переходного периода.

Для дополнительного слоя защиты SSH можно использовать отдельную схему двухфакторной аутентификации, описанную в руководстве по SSH 2FA через TOTP и аппаратные ключи.

Расширение миграции и контроль результата

После успешного пилота распределяйте конфигурацию волнами: сначала staging, затем некритичные production-серверы, после этого узлы с высокой ценой простоя. Используйте существующую систему управления конфигурациями, чтобы одинаково распространять:

• публичный ключ CA;
• фрагмент sshd-конфигурации;
• principal-файлы;
• актуальный KRL;
• права владельца и режима файлов.

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

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

Удаление старых ключей и процедура отката

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

Аварийный механизм должен оставаться доступным. Это может быть отдельная учетная запись с сертификатом короткого TTL, консольный доступ или заранее проверенный резервный ключ, хранящийся по контролируемой процедуре.

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

1. остановить удаление старых ключей;
2. вернуть проверенную копию authorized_keys;
3. восстановить прежнюю конфигурацию sshd или отключить новые директивы;
4. проверить sshd -t;
5. выполнить reload и открыть новую тестовую сессию;
6. зафиксировать причину сбоя и результат восстановления.

До завершения миграции не удаляйте единственный способ попасть на сервер. Для production-среды полезно заранее проверить базовое усиление SSH и права доступа по чек-листу hardening Linux-сервера.

Диагностика SSH-сертификатов OpenSSH

Сертификат не подхватывается клиентом

Сначала отделите проблему клиента от отказа сервера. Проверьте наличие файлов:

ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519-cert.pub

Если сертификат имеет стандартное имя id_ed25519-cert.pub, OpenSSH обычно находит его рядом с закрытым ключом. Для нестандартного имени укажите параметры явно:

ssh -vvv \
  -o IdentityFile=~/.ssh/work_key \
  -o CertificateFile=~/.ssh/work_key-cert.pub \
  user@server

В выводе -vvv ищите попытку загрузить закрытый ключ и сертификат. Сертификат не может заменить закрытый ключ: клиент должен доказать владение соответствующей ключевой парой.

Сервер отклоняет principal или срок действия

Сверьте principal сертификата с содержимым файла:

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub
sudo cat /etc/ssh/auth_principals/alice

Проверьте valid-after и valid-before. Ошибка часто возникает из-за неверного времени на сервере, рабочей станции или машине CA:

date -u
timedatectl status

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

Ошибки CA, прав доступа и KRL

Проверьте эффективные значения параметров:

sudo sshd -T | grep -E 'trustedusercakeys|authorizedprincipalsfile|revokedkeys'

Убедитесь, что:

• на сервере размещен именно публичный ключ нужного CA;
• отпечаток CA совпадает с утвержденным значением;
• sshd может читать файлы CA, principals и KRL;
• в конфигурации нет дублирующей директивы, которая меняет ожидаемое поведение;
• KRL проверяется командой ssh-keygen -Q -f;
• после изменения выполнены sshd -t и reload;
• логи проверяются на том сервере, куда выполняется новое подключение.

В Debian и Ubuntu чаще используются служба ssh и файл /var/log/auth.log. В RHEL-подобных системах встречаются служба sshd и /var/log/secure. При использовании journald основной инструмент, journalctl.

Эксплуатационный чек-лист SSH CA

• Закрытый ключ CA хранится отдельно от серверов и защищен passphrase.
• Есть зашифрованная резервная копия CA и проверена процедура восстановления.
• На серверы передается только публичный ключ CA.
• Для каждого сертификата записаны key ID, serial, владелец, principal, TTL и назначение.
• Principals ограничены через AuthorizedPrincipalsFile или контролируемую команду.
• TTL соответствует риску: для интерактивного доступа задан короткий срок, для автоматизации предусмотрено обновление.
• Расширения и critical options соответствуют минимально необходимым полномочиям.
• KRL создается, обновляется и распространяется на все целевые серверы.
• Проверены ssh-keygen -L, ssh-keygen -Q, ssh -vvv и серверные журналы.
• Время на CA, клиентах и серверах синхронизировано.
• Изменения sshd проходят через sshd -t, а reload проверяется новой SSH-сессией.
• Старые записи authorized_keys удаляются только после пилота и периода наблюдения.
• Есть резервный канал доступа и документированный rollback.

Для тестового стенда или временной инфраструктуры сертификаты можно проверять на отдельном облачном сервере, например в Timeweb Cloud. Рабочий CA при этом не следует размещать на том же узле, который выдает пользовательские SSH-сертификаты.

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