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

Привет, это Вася из Fastfox. Сегодня разберём практичную схему, которую часто недооценивают на небольших и средних инфраструктурах: OpenSSH CA для доступа на VDS. Если у вас один сервер и два администратора, обычный authorized_keys ещё терпим. Но как только появляются продакшен, staging, CI, отдельные пользователи для деплоя, временные подрядчики и несколько Linux-серверов, ручное копирование публичных ключей превращается в источник ошибок.

SSH-сертификаты OpenSSH решают эту проблему без LDAP, без тяжёлой IAM-платформы и без внешней зависимости. На сервере хранится публичный ключ центра сертификации, а пользователь подключается с обычным SSH-ключом плюс короткоживущим сертификатом, подписанным вашим CA. Сервер проверяет подпись, срок действия и список разрешённых principals. В результате вы управляете доступом централизованно: выдали сертификат на 8 часов, ограничили ролью, отозвали при необходимости — и не ходите по всем VDS с правкой authorized_keys.

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

Что такое OpenSSH CA и чем он отличается от обычных SSH-ключей

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

В схеме с OpenSSH CA серверу не нужно знать публичные ключи всех пользователей. Он знает только публичный ключ вашего CA через параметр TrustedUserCAKeys. Пользовательский публичный ключ подписывается приватным ключом CA командой ssh-keygen -s. Получается файл сертификата вида id_ed25519-cert.pub. При входе клиент предъявляет и ключ, и сертификат.

Важно: OpenSSH CA — это не X.509 PKI и не TLS-сертификаты. Это встроенный механизм OpenSSH для SSH user certificates и host certificates. В этой статье фокусируемся на пользовательских сертификатах для входа на Linux-серверы.

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

Когда SSH-сертификаты особенно полезны на VDS

На VDS обычно начинают с простого: отключили парольный вход, добавили ключи администраторам, настроили firewall. Это нормальный старт. Но дальше инфраструктура обрастает задачами: деплой из CI, доступ дежурных инженеров, отдельный пользователь для бэкапов, bastion-хост, временный доступ на диагностику. В этот момент сертификаты дают аккуратный контроль без тяжёлой бюрократии.

• Временный доступ. Сертификат можно выдать на 30 минут, 8 часов или неделю. По окончании срока он перестанет работать сам.
• Единая точка доверия. На каждом сервере лежит один CA public key, а не десятки пользовательских ключей.
• Роли через principals. Один и тот же человек может получить сертификат с principal deploy для деплоя или admin для администрирования.
• Меньше забытых ключей. Удаление сотрудника из процесса выдачи сертификатов эффективнее, чем ручная зачистка всех authorized_keys.
• Удобно для CI/CD. Пайплайн может получать короткоживущий сертификат и не хранить долгоживущий доступ ко всем серверам.

При этом OpenSSH CA не отменяет базовую гигиену: приватные ключи пользователей должны быть защищены passphrase или аппаратным токеном, root-вход лучше отключать, sudo выдавать по минимуму, а аварийный доступ держать отдельно и проверять до изменений.

План настройки

Мы соберём рабочую схему из пяти частей. Сначала создадим ключ CA на административной машине. Затем установим публичный ключ CA на VDS и включим TrustedUserCAKeys в sshd_config. После этого настроим AuthorizedPrincipalsFile, чтобы сервер понимал, какие certificate principals разрешены конкретному локальному пользователю. Потом подпишем пользовательский ключ командой ssh-keygen -s и проверим вход. В конце разберём отзыв, ротацию и типовые ошибки.

В примерах будем использовать такие имена:

• ca_user_ed25519 — приватный ключ пользовательского CA;
• ca_user_ed25519.pub — публичный ключ CA, который попадёт на VDS;
• admin — локальный пользователь на сервере;
• vasya и admin — principals в сертификате;
• /etc/ssh/auth_principals/%u — файл разрешённых principals для каждого локального пользователя.

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

Устанавливаем OpenSSH и проверяем версии

На большинстве актуальных Linux-дистрибутивов поддержка SSH-сертификатов уже есть. Но полезно проверить, что установлен и клиент, и сервер OpenSSH, особенно на минимальных образах VDS.

Debian и Ubuntu

sudo apt update
sudo apt install openssh-client openssh-server
ssh -V
sudo sshd -T | grep trustedusercakeys

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux

sudo dnf install openssh-clients openssh-server
ssh -V
sudo sshd -T | grep trustedusercakeys

Fedora

sudo dnf install openssh-clients openssh-server
ssh -V
sudo sshd -T | grep trustedusercakeys

Если команда sshd -T показывает строку с trustedusercakeys, сервер понимает нужную директиву. На очень старых системах лучше обновить OpenSSH или саму ОС: строить новую схему доступа на устаревшем SSH-сервере не стоит.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Создаём ключ CA

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

Создадим Ed25519-ключ CA. Делайте это на машине администратора, не на целевом сервере:

mkdir -p ~/.ssh/ca
chmod 700 ~/.ssh/ca
ssh-keygen -t ed25519 -f ~/.ssh/ca/ca_user_ed25519 -C openssh-user-ca-2026

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

Публичный ключ CA можно посмотреть так:

ssh-keygen -l -f ~/.ssh/ca/ca_user_ed25519.pub
cat ~/.ssh/ca/ca_user_ed25519.pub

Именно публичный ключ мы перенесём на VDS. Приватный ключ ca_user_ed25519 на сервер копировать не нужно.

Настраиваем TrustedUserCAKeys на VDS

Теперь на каждом сервере, который должен принимать сертификаты, создаём файл с публичным ключом CA. Название может быть любым, но удобно держать его в /etc/ssh.

sudo install -d -m 755 -o root -g root /etc/ssh/ca
sudo install -m 644 -o root -g root ca_user_ed25519.pub /etc/ssh/ca/user_ca.pub

Если вы переносите файл через scp, сначала положите его во временное место, а затем выполните install с правильными владельцем и правами. На системах с SELinux после копирования в нестандартный путь полезно восстановить контекст:

sudo restorecon -Rv /etc/ssh/ca

Добавим директивы в конфигурацию OpenSSH. В новых системах удобно использовать отдельный файл в каталоге /etc/ssh/sshd_config.d. Если такой каталог не подключён в вашем sshd_config, добавьте строки непосредственно в основной файл.

sudo mkdir -p /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/20-user-ca.conf > /dev/null <<EOF
TrustedUserCAKeys /etc/ssh/ca/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/auth_principals/%u
PubkeyAuthentication yes
EOF

Параметр TrustedUserCAKeys говорит sshd, каким CA доверять для пользовательских сертификатов. Параметр AuthorizedPrincipalsFile указывает, где искать список principals, разрешённых для локального пользователя. Шаблон %u заменяется именем пользователя, под которым выполняется вход.

Проверьте конфигурацию до перезагрузки сервиса:

sudo sshd -t

Если команда ничего не вывела и завершилась успешно, можно перечитать конфигурацию.

Debian и Ubuntu

sudo systemctl reload ssh

RHEL-based и Fedora

sudo systemctl reload sshd

Не закрывайте текущую SSH-сессию, пока не проверите новый вход в отдельном терминале.

Настраиваем authorized principals

Теперь сервер доверяет CA, но ещё не знает, какие certificate principals можно использовать для конкретного локального аккаунта. Создадим каталог и файл для пользователя admin. Внутри файла каждая строка — один разрешённый principal.

sudo install -d -m 755 -o root -g root /etc/ssh/auth_principals
sudo tee /etc/ssh/auth_principals/admin > /dev/null <<EOF
vasya
admin
EOF
sudo chown root:root /etc/ssh/auth_principals/admin
sudo chmod 644 /etc/ssh/auth_principals/admin

Теперь пользователь сможет войти как локальный admin, если его сертификат подписан доверенным CA, не просрочен и содержит principal vasya или admin. Если в сертификате только deploy, вход в admin будет отклонён.

Такая модель хорошо ложится на роли. Например, для локального пользователя deploy можно разрешить только principal ci-prod и release-manager, а для backup — только backup-readonly. Это удобнее, чем хранить один и тот же публичный ключ в разных аккаунтах без контекста, зачем он там лежит.

Подписываем пользовательский ключ через ssh-keygen

На машине пользователя уже должен быть обычный SSH-ключ. Если его нет, создайте:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C vasya-laptop

Публичный ключ ~/.ssh/id_ed25519.pub передаётся администратору CA или подписывается в вашей автоматизированной процедуре. Подпишем его на 8 часов с principals vasya и admin, идентификатором сертификата и серийным номером:

ssh-keygen -s ~/.ssh/ca/ca_user_ed25519 -I vasya-admin-2026-01-15 -n vasya,admin -V +8h -z 1001 ~/.ssh/id_ed25519.pub

Команда создаст файл ~/.ssh/id_ed25519-cert.pub. Это и есть пользовательский SSH-сертификат. Приватный ключ пользователя остаётся прежним, а сертификат можно перевыпускать сколько угодно раз с разными сроками и principals.

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

ssh-keygen -Lf ~/.ssh/id_ed25519-cert.pub

В выводе проверьте Signing CA, Key ID, Serial, Valid и Principals. Если срок действия задан неправильно, лучше не пытаться лечить готовый сертификат, а подписать ключ заново.

Подключаемся к VDS с сертификатом

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

ssh admin@server.example

Для явного указания ключа и сертификата используйте:

ssh -i ~/.ssh/id_ed25519 -o CertificateFile=~/.ssh/id_ed25519-cert.pub admin@server.example

Удобнее прописать это в ~/.ssh/config на рабочей станции:

Host prod-vds
    HostName server.example
    User admin
    IdentityFile ~/.ssh/id_ed25519
    CertificateFile ~/.ssh/id_ed25519-cert.pub
    IdentitiesOnly yes

Если вход не проходит, включите подробный вывод:

ssh -vvv prod-vds

В логе клиента ищите строки про предложение сертификата. На сервере смотрите журнал sshd. В Debian и Ubuntu обычно так:

sudo journalctl -u ssh -n 100 --no-pager

В RHEL-based и Fedora:

sudo journalctl -u sshd -n 100 --no-pager

Если параллельно усиливаете SSH-политику, посмотрите материал про современные шифры, KEX и MAC в OpenSSH: сертификаты решают управление доступом, но не заменяют настройку криптографических алгоритмов.

Сроки действия: короткие сертификаты лучше долгих

Главное преимущество SSH-сертификатов — встроенный TTL. Не превращайте их в вечные ключи. Для интерактивного админского доступа часто достаточно 4–12 часов. Для планового релиза — срок окна деплоя. Для временного подрядчика — конкретный период работ. Долгие сертификаты на месяцы имеют смысл только там, где уже есть отдельная процедура контроля, журналирования и быстрого отзыва.

Примеры сроков в ssh-keygen -V:

ssh-keygen -s ~/.ssh/ca/ca_user_ed25519 -I vasya-short -n vasya -V +4h -z 1002 ~/.ssh/id_ed25519.pub
ssh-keygen -s ~/.ssh/ca/ca_user_ed25519 -I ci-nightly -n ci-prod -V 20260115:20260116 -z 1003 ./ci_deploy.pub
ssh-keygen -s ~/.ssh/ca/ca_user_ed25519 -I contractor-week -n support -V 20260115:20260122 -z 1004 ./contractor.pub

Идентификатор -I выбирайте так, чтобы он помогал расследовать события: имя владельца, назначение, дата, тикет или номер заявки. Серийный номер -z ведите монотонно и сохраняйте в журнале выдачи. Даже простая таблица с serial, key id, principals, сроком и кем выдано уже сильно упрощает эксплуатацию.

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

Короткий срок действия снижает потребность в отзыве, но полностью её не отменяет. Если ноутбук с ключом потерян, доступ выдан ошибочно или нужно немедленно закрыть сертификат до окончания TTL, используйте RevokedKeys. OpenSSH умеет читать как список отозванных ключей, так и KRL — Key Revocation List.

Создадим KRL на административной машине, указав сертификат, который нужно отозвать:

ssh-keygen -k -f revoked_user_certs.krl ~/.ssh/id_ed25519-cert.pub

Перенесите KRL на сервер и подключите в конфигурации sshd:

sudo install -m 644 -o root -g root revoked_user_certs.krl /etc/ssh/revoked_user_certs.krl
sudo tee /etc/ssh/sshd_config.d/21-revoked-user-certs.conf > /dev/null <<EOF
RevokedKeys /etc/ssh/revoked_user_certs.krl
EOF
sudo sshd -t

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

В малой инфраструктуре часто достаточно политики коротких сертификатов плюс отзыв только в аварийных случаях. В большой — лучше автоматизировать публикацию KRL на все VDS через Ansible, Salt, rsync с проверкой хеша или другой привычный инструмент управления конфигурацией.

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

Сертификат OpenSSH может содержать ограничения. По умолчанию пользовательские сертификаты обычно получают стандартные extensions, разрешающие интерактивную работу, agent forwarding, port forwarding и другие возможности. Для админов это может быть нормально, но для CI или сервисных пользователей лучше ограничить лишнее.

Например, можно запретить pty и forwarding, оставив сертификат только для выполнения команды или деплоя. Практическая политика зависит от вашего процесса, но принцип такой: не выдавайте универсальный сертификат там, где нужна узкая роль.

ssh-keygen -s ~/.ssh/ca/ca_user_ed25519 -I ci-prod-1005 -n ci-prod -V +1h -z 1005 -O clear -O no-pty -O no-agent-forwarding -O no-port-forwarding -O no-X11-forwarding ./ci_deploy.pub

Опция -O clear очищает стандартный набор extensions, после чего вы добавляете только нужные ограничения или разрешения. Проверяйте итог командой ssh-keygen -Lf, потому что ошибка в наборе опций может либо сломать деплой, либо оставить лишние возможности.

Безопасная эксплуатация CA

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

• Храните приватный CA key отдельно от VDS, на защищённой машине или аппаратном носителе.
• Используйте passphrase и ограниченные права на файл: chmod 600.
• Ведите журнал выдачи сертификатов: serial, key id, principals, срок, владелец, основание.
• Разделяйте CA по назначению: user CA для пользователей, отдельный host CA для хостовых сертификатов, если он вам нужен.
• Не выдавайте сертификаты с лишними principals. Роль admin не должна попадать в CI без необходимости.
• Периодически проверяйте серверы: какой CA подключён, нет ли старых authorized_keys, не включён ли парольный вход.

Хорошая практика — оставить аварийный способ доступа, но защитить его строже и документировать. Например, отдельный break-glass ключ у двух ответственных администраторов, отключённый парольный вход и проверенный доступ через консоль провайдера на случай ошибки в sshd.

Как мигрировать с authorized_keys без простоя

Не удаляйте старые ключи сразу. Безопасная миграция выглядит так: сначала добавляете TrustedUserCAKeys и AuthorizedPrincipalsFile, проверяете sshd -t, перечитываете sshd, тестируете вход по сертификату в новой сессии. Только после этого постепенно чистите authorized_keys.

1. Создайте CA key и защитите его.
2. Установите public CA key на один тестовый VDS.
3. Настройте principals для одного пользователя.
4. Выпустите короткий тестовый сертификат на 15–30 минут.
5. Проверьте вход, sudo, деплойные команды и журналы.
6. Повторите на остальных серверах через систему управления конфигурацией.
7. Удаляйте старые ключи только после подтверждения, что сертификатный доступ работает.

Для аудита полезно временно оставить комментарии в authorized_keys и сравнить их с журналом выдачи сертификатов. Часто на этом этапе находятся забытые ключи бывших сотрудников, старые CI-ключи и доступы, назначение которых уже никто не помнит.

Типовые ошибки и диагностика

Ошибка номер один — сервер доверяет CA, но principal не разрешён локальному пользователю. В этом случае сертификат может быть корректным, срок действия нормальный, но вход всё равно отклоняется. Проверяйте вывод ssh-keygen -Lf и файл /etc/ssh/auth_principals/имя_пользователя.

Ошибка номер два — сертификат не подхватывается клиентом. Убедитесь, что файл называется id_ed25519-cert.pub и лежит рядом с id_ed25519, либо явно укажите CertificateFile. Если в ssh-agent загружено много ключей, используйте IdentitiesOnly yes.

Ошибка номер три — неверные права или SELinux-контекст. Файлы в /etc/ssh должны принадлежать root и быть читаемыми sshd. На RHEL-based системах после ручного копирования выполните restorecon. Если включён SELinux enforcing, не игнорируйте AVC-события в журнале.

Ошибка номер четыре — забыли проверить конфигурацию перед reload. Команда sshd -t должна стать рефлексом. Ещё лучше — держать отдельный конфигурационный файл для CA, чтобы откат сводился к удалению одного файла и reload.

sudo rm /etc/ssh/sshd_config.d/20-user-ca.conf
sudo sshd -t
sudo systemctl reload sshd

На Debian и Ubuntu в последней строке обычно будет sudo systemctl reload ssh. Перед откатом проверьте имя сервиса командой systemctl status ssh или systemctl status sshd.

Минимальный чек-лист для продакшена

Перед тем как считать схему готовой, пройдитесь по короткому чек-листу. Он помогает поймать неочевидные проблемы до того, как сертификаты станут основным способом доступа.

• TrustedUserCAKeys указывает на правильный public CA key.
• AuthorizedPrincipalsFile включён и файлы principals созданы для нужных пользователей.
• Старые authorized_keys либо очищены, либо документированы как временный fallback.
• Сертификаты выдаются с коротким TTL и понятным Key ID.
• Serial не повторяется и записывается в журнал выдачи.
• Для CI и сервисных ролей отключены ненужные возможности: pty, agent forwarding, port forwarding.
• Есть процедура отзыва через KRL и понятный способ доставить KRL на все серверы.
• Есть проверенный аварийный доступ и инструкция отката.

Если всё это выполнено, OpenSSH CA становится не экспериментом, а нормальным административным инструментом. Он особенно хорошо подходит для VDS-инфраструктуры: минимум компонентов, нативная поддержка в OpenSSH, понятная диагностика и отсутствие необходимости разворачивать отдельный тяжёлый сервис ради управления SSH-доступом.

Итоги

OpenSSH CA — простой способ навести порядок в SSH-доступе к Linux VDS. Вместо того чтобы раскладывать публичные ключи по серверам, вы доверяете одному CA, выдаёте короткоживущие сертификаты и управляете ролями через authorized principals. Параметр TrustedUserCAKeys включает доверие к вашему CA, AuthorizedPrincipalsFile связывает principals с локальными аккаунтами, а ssh-keygen -s выпускает сертификаты с нужным TTL и ограничениями.

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