SSH-ключи: типы, срок действия и безопасное хранение

SSH-ключ — долгоживущий пропуск на сервер, и ошибки при его выборе или хранении обходятся дороже, чем кажется. Открытый ключ можно передавать, приватный нельзя копировать на сервер, а бессрочный доступ сотрудника часто действует ещё годы после ухода. Разберём типы ключей, срок действия и практику хранения, чтобы доступ можно было выдать, проверить и отозвать. Речь только о собственной инфраструктуре и защите своих серверов.

Какие типы ключей использовать

По умолчанию ssh-keygen создаёт Ed25519: компактный, быстрый и не требующий выбора длины. Для новых ключей это разумный выбор. RSA остаётся для совместимости: рекомендуемая длина — 3072 бита и больше, подпись rsa-sha2-256 или rsa-sha2-512. ECDSA поддерживается, но преимуществ перед Ed25519 не даёт. DSA в актуальных OpenSSH удалён, такие ключи нужно заменить. В свежих выпусках появился гибридный mldsa44-ed25519 — его стоит применять, только если обновлены и клиент, и сервер.

ssh -V
ssh -Q key
ssh -Q key-sig
ssh-keygen -lf ~/.ssh/id_ed25519.pub

Отпечаток по умолчанию выводится в SHA256; MD5 остался для совместимости со старыми системами. Отдельная категория — аппаратные ключи FIDO2 (sk-ssh-ed25519@openssh.com). Приватная часть хранится в токене, для входа нужно касание, а с verify-required ещё и PIN. Это лучший вариант для административного доступа с ноутбука.

Генерация под задачу

Не используйте один ключ для GitHub, домашнего сервера и работы: отдельный ключ на роль проще отозвать. Комментарий должен указывать владельца и дату. Параметр -a 100 увеличивает число итераций bcrypt для парольной фразы, а ssh-keygen -p меняет фразу и пересчитывает KDF у существующего ключа.

ssh-keygen -t ed25519 -a 100 -C "alice@laptop-2026-11"
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "alice@token"
ssh-keygen -p -a 100 -f ~/.ssh/id_ed25519

Если без RSA обойтись нельзя, берите 4096 бит и проверяйте, что сервер принимает rsa-sha2-512. Пустая фраза допустима только для служебного ключа с ограниченными правами. Для FIDO-ключа resident позволяет носить его между машинами, но при потере токена риск выше, поэтому резервный аппаратный ключ регистрируют заранее.

Срок действия: что умеет OpenSSH

У обычного ключа нет встроенного срока действия: он действует, пока его строка есть в authorized_keys. Параметр expiry-time ограничивает конкретную запись. Формат — YYYYMMDD или YYYYMMDDHHMM[SS]; время трактуется в часовом поясе системы, а суффикс Z задаёт UTC. Ограничение from= сужает доступ по адресам, но не заменяет сетевой периметр. Для временного доступа коллеге хватит записи с expiry-time, для постоянной команды лучше подходят сертификаты.

expiry-time="20270301Z",from="203.0.113.0/24" ssh-ed25519 AAAAC3... alice@laptop
ssh-keygen -lf ~/.ssh/authorized_keys

Для массового управления сроком лучше подходят SSH-сертификаты: доступ на 8 часов, 30 дней или год, принципалы и ограничения проверяются централизованно по ключу CA. Сертификат не заменяет ключ: рядом с обычной парой появляется файл id_ed25519-cert.pub. Короткий срок удобнее тем, что истекающий доступ не нужно искать по всем authorized_keys.

Сертификаты на практике

CA-ключ создаётся один раз и хранится отдельно от пользовательских машин, желательно на аппаратном токене. Приватный ключ CA не должен лежать на сервере, который принимает сертификаты.

ssh-keygen -t ed25519 -f ca_key -C "SSH CA 2026"
ssh-keygen -s ca_key -I alice-2026-11 -n alice,deploy -V +52w -z 1042 id_ed25519.pub
ssh-keygen -L -f id_ed25519-cert.pub

-n перечисляет принципалов, -V +52w задаёт срок, -z — серийный номер для отзыва. На сервере добавьте в sshd_config директиву:

TrustedUserCAKeys /etc/ssh/ca.pub
# RevokedKeys /etc/ssh/revoked_keys

Затем проверьте sshd -t и перезагрузите службу. Записи в authorized_keys после этого не нужны. Если принципал не совпадает с системным пользователем, понадобится AuthorizedPrincipalsFile. Опции -O no-port-forwarding и -O source-address=203.0.113.0/24 сужают возможности сертификата.

Безопасное хранение

Права доступа — не формальность: OpenSSH откажется использовать ключ, если файл доступен на запись другим. Держите каталог с правами 700, приватный ключ — 600, открытый — 644. Приватный ключ храните на зашифрованном диске и не синхронизируйте через облако в открытом виде. Для резервной копии используйте отдельное шифрование: age -p -o id_ed25519.age id_ed25519. Аппаратный токен снимает проблему копирования, но требует резервного носителя и понятной процедуры восстановления.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
ls -la ~/.ssh

Агент хранит расшифрованный ключ в памяти, поэтому ограничьте время: ssh-add -t 8h ~/.ssh/id_ed25519. Не пересылайте приватный ключ по почте или в мессенджере. Не включайте ForwardAgent yes на серверах: администратор промежуточной машины сможет использовать ваш агент. Для перехода через бастион применяйте ProxyJump, а в ~/.ssh/config — IdentitiesOnly yes и явный IdentityFile.

Ротация и отзыв

Ведите инвентарь: владелец, отпечаток, назначение, дата, срок и где установлен открытый ключ. При увольнении, потере устройства или подозрении на компрометацию ключ удаляют из всех authorized_keys, а сертификаты отзывают через KRL. Сертификат можно отозвать по серийному номеру, не имея самого файла.

ssh-keygen -k -f revoked_keys id_ed25519-cert.pub
ssh-keygen -Q -f revoked_keys id_ed25519-cert.pub
ssh-keygen -k -u -f revoked_keys old_key.pub

Файл revoked_keys подключается директивой RevokedKeys. Ключ -u добавляет запись в существующий список. После изменений проверяйте sshd -t и держите открытой отдельную сессию. Смотрите журналы: journalctl -u ssh --since "24 hours ago", lastlog и успешные входы с незнакомых адресов. Если ключ скомпрометирован, проверьте все хосты, где он мог быть установлен.

Чек-лист

• Ed25519 для новых ключей, RSA 3072+ только для совместимости.
• Отдельный ключ на роль, содержательный комментарий, парольная фраза.
• Права 700/600, шифрование диска, отдельная зашифрованная копия.
• Срок через сертификат или expiry-time.
• Инвентарь отпечатков, KRL для отзыва, проверка восстановления доступа.
• Резервный ключ проверен до того, как основной потерян.

Итог

Безопасность SSH-ключей складывается из типа ключа, управляемого срока и дисциплины хранения. Ed25519 закрывает большинство сценариев, сертификаты дают предсказуемую ротацию, аппаратный токен защищает самый ценный секрет. Не храните приватные ключи на серверах и не оставляйте бессрочный доступ «на всякий случай». Проверьте схему сегодня: найдите все ключи, которые принимает сервер, и ответьте, кому и зачем каждый выдан. Ротация без проверки доступа — только запись в журнале.