# 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/uk/kb/dvuhfaktornaya-autentifikatsiya-server/) для входу по SSH.

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

---

Джерело: https://www.zevshost.net/uk/kb/ssh-sertifikaty-ca/