Чим погане ручне керування 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-сертифікати: вхід через центр сертифікації