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

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

## Чем плохо ручное управление 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` синхронизируется на все серверы при каждом отзыве.
- Дополнительно к сертификатам включена [двухфакторная аутентификация](https://www.zevshost.net/ru/kb/dvuhfaktornaya-autentifikatsiya-server/) для входа по SSH.

SSH CA не заменяет базовый [SSH hardening](https://www.zevshost.net/ru/kb/ssh-hardening-server/) — отключённый вход по паролю и смену порта настраивайте отдельно. Сравнение с классической раздачей ключей — в статье про [SSH-ключи для входа на VPS](https://www.zevshost.net/ru/kb/ssh-klyuchi-vds/).

---

Источник: https://www.zevshost.net/ru/kb/ssh-sertifikaty-ca/