Чем плохо ручное управление SSH-ключами

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

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

Как работает SSH CA

Модель строится на паре ключей самого центра сертификации:

CA хранит приватный ключ и подписывает публичные ключи пользователей или хостов, выдавая сертификат с ограниченным сроком действия.
Серверы настраивают доверие к публичному ключу CA один раз через параметр TrustedUserCAKeys в sshd_config.
Пользователь при подключении предъявляет сертификат вместо голого ключа — sshd проверяет подпись CA и срок действия.

Такая же схема работает и в обратную сторону — Host CA подписывает ключи серверов, и клиент перестаёт получать предупреждение о недоверенном хосте при первом подключении к новому серверу.

Настройка центра сертификации

Разверните CA на отдельной защищённой машине, не на рабочем сервере:

ssh-keygen -t ed25519 -f /etc/ssh-ca/user_ca -C "zevshost-user-ca"
ssh-keygen -t ed25519 -f /etc/ssh-ca/host_ca -C "zevshost-host-ca"

Приватные ключи user_ca и host_ca храните офлайн или в отдельном хранилище секретов — компрометация CA даёт доступ ко всем серверам, доверяющим ему.

Выпуск сертификата для пользователя

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

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
ssh-keygen -s /etc/ssh-ca/user_ca -I "ivan@zevshost" \
    -n ivan -V +12h -z 1001 ~/.ssh/id_ed25519.pub

Флаг -V +12h ограничивает срок действия сертификата 12 часами — после истечения потребуется новый выпуск. Флаг -n задаёт список принципалов (логинов), для которых действует сертификат, а -z — серийный номер для точечного отзыва.

Настройка сервера под сертификаты

На каждом сервере, который должен доверять CA, добавьте в /etc/ssh/sshd_config:

TrustedUserCAKeys /etc/ssh/user_ca.pub
HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
RevokedKeys /etc/ssh/revoked_keys

Файл user_ca.pub — это публичный ключ CA, скопированный с CA-сервера, а не приватный. Далее перезапустите sshd:

sudo systemctl restart sshd

Отзыв конкретного сертификата — это добавление его серийного номера или ключа пользователя в файл revoked_keys через ssh-keygen -k, без переустановки доступа на остальных серверах.

Чек-лист внедрения SSH CA

CA развёрнут на отдельной машине, приватный ключ CA не покидает защищённое хранилище.
Сертификаты пользователей выпускаются с TTL 12 часов и обязательным списком принципалов.
Серверы настроены на доверие CA через TrustedUserCAKeys, обычные ключи в authorized_keys постепенно выводятся из обращения.
Список отзыва RevokedKeys синхронизируется на все серверы при каждом отзыве.
Дополнительно к сертификатам включена двухфакторная аутентификация для входа по SSH.

SSH CA не заменяет базовый SSH hardening — отключённый вход по паролю и смену порта настраивайте отдельно. Сравнение с классической раздачей ключей — в статье про SSH-ключи для входа на VPS.

SSH-сертификаты: вход через центр сертификации