SSH-сертификаты для команды: доступ к VPS на восемь часов

MAATRIX · 17 октября 2026 · 8 мин чтения

Публичный SSH-ключ удобно добавить на сервер. Через год неудобно выяснять, кому принадлежат семь строк в authorized_keys и на каких ещё машинах лежит каждая из них. Комментарий work-laptop-new обычно не помогает: новый ноутбук за это время успел стать старым.

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

Проверим схему на отдельном VPS и выдадим учебный доступ на восемь часов. Это сертификаты OpenSSH, а не сертификаты HTTPS; публичный удостоверяющий центр для них не нужен.

Три сущности, которые нельзя перепутать

У пользователя есть пара ключей. Закрытый ключ хранится на его устройстве, публичный передаётся администратору. Центр выдачи, или CA, имеет собственную пару: закрытым ключом он подписывает разрешения, публичному ключу доверяют серверы.

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

Компрометация пользовательского ключа затрагивает его доступ. Компрометация закрытого ключа CA может позволить выпускать новые разрешения, поэтому его защищают гораздо строже. Не храните CA рядом с приложением на том же VPS, куда выдаёте доступ.

Для первого теста достаточно офлайн-выдачи с доверенного административного компьютера. Для команды позже можно организовать отдельный сервис выдачи с аутентификацией и аудитом, но начинать с него необязательно.

Кто имеет право подписывать доступ

Центр сертификации становится точкой, в которой техническое действие встречается с организационным решением. Подпись должна отвечать на конкретную заявку: кому, на какие машины и на какой срок нужен вход. Если сотрудник сам выбирает произвольный principal и отправляет его в автоматический подписывающий скрипт, ограничение срока лишь делает произвольный доступ недолгим.

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

Если подписывание переносится в сервис, его аутентификация и политика становятся отдельной задачей. Для штатного сотрудника, временного подрядчика и аварийного администратора нужны разные условия. Долгий срок аварийного сертификата не заменяет проверенный резервный способ доступа через консоль провайдера.

Часы сервера участвуют в безопасности

Временное разрешение проверяется по часам принимающей стороны. Поэтому перед запуском процесса убедитесь, что синхронизация времени включена и работает на всех целевых машинах. Сдвиг в несколько минут способен объяснить отказ нового сертификата, а значительный сдвиг делает рассуждения о сроке действия ненадёжными.

Небольшое начало срока в прошлом в учебной команде компенсирует обычное расхождение, но не лечит сломанное время. При диагностике сохраните вывод проверки сертификата и время сервера, а затем сравните principal, пользователя операционной системы и доверенный CA. Не продлевайте сертификат на месяц только ради исчезновения ошибки: так диагностическая случайность становится постоянным правилом доступа.

Подготовьте путь назад

Используйте тестовый сервер с существующим административным входом и доступом к консоли провайдера. Оставьте текущую SSH-сессию открытой до окончания проверки. Не отключайте прежний способ входа одновременно с добавлением нового.

Для такого стенда достаточно MAATRIX Ba Lite с 1 vCPU и 2 GB памяти. Важны поддерживаемая Ubuntu или Debian, актуальный OpenSSH и синхронизированное время. На одной машине удобно проверить отказ и восстановление, не затрагивая рабочие подключения команды.

Создайте отдельную Linux-учётную запись для учебного пользователя alice по принятой в вашей системе процедуре. Не выдавайте ей sudo, если задача этого не требует. Сертификат разрешает вход, но права файлов и команды всё равно определяются локальной учётной записью.

Проверьте часы сервера и компьютера выдачи. Даже правильно подписанный сертификат будет отвергнут, если система считает, что его срок ещё не наступил или уже закончился.

Создаём CA и пользовательский ключ

На доверенном административном устройстве создайте ключ CA:

ssh-keygen -t ed25519 -f team_user_ca -C 'team user CA'

Задайте стойкую парольную фразу. Файл team_user_ca — секрет центра выдачи, team_user_ca.pub — публичная часть. Сделайте защищённую резервную копию и ограничьте доступ к закрытому файлу.

Пользователь на своём компьютере создаёт личную пару:

ssh-keygen -t ed25519 -f ~/.ssh/team_ed25519 -C 'alice workstation'

В центр выдачи передаётся только team_ed25519.pub. Закрытый файл не нужно пересылать администратору, загружать на VPS или прикладывать к заявке. Проверяйте принадлежность публичного ключа пользователю через принятый доверенный канал.

Возможности и форматы команды описаны в руководстве ssh-keygen. Имена файлов в примере учебные; для рабочей системы полезно вести реестр пользователей, отпечатков и выданных сертификатов.

Подписываем разрешение на рабочий день

На устройстве CA выполните команду для полученного публичного ключа:

ssh-keygen -s team_user_ca \
  -I alice-request-104 \
  -n alice \
  -V -5m:+8h \
  -z 1001 \
  -O clear \
  -O permit-pty \
  team_ed25519.pub

-I задаёт идентификатор для журналов, -n — разрешённое имя, -z — серийный номер. Интервал начинается немного раньше текущего времени, чтобы небольшой сдвиг часов не мешал проверке, и заканчивается через восемь часов. Серийные номера в рабочей процедуре должны быть управляемыми и уникальными в пределах принятой схемы.

Мы очистили дополнительные разрешения и включили PTY для интерактивной работы. Не добавляйте перенаправление агента или портов автоматически: разрешайте только то, что требуется задаче. Если пользователь должен выполнять одну команду, исследуйте соответствующие ограничения сертификата отдельно.

Результат появится в team_ed25519-cert.pub. Проверьте содержимое:

ssh-keygen -L -f team_ed25519-cert.pub

Сверьте principal, срок и ограничения. Передайте сертификат пользователю, чтобы он положил его рядом с соответствующим закрытым ключом.

Учим сервер доверять вашему CA

На тестовый VPS передайте только публичный ключ team_user_ca.pub. Установите его, например, как /etc/ssh/team_user_ca.pub, с владельцем root и без права изменения обычными пользователями.

Добавьте в подходящий конфигурационный файл sshd:

TrustedUserCAKeys /etc/ssh/team_user_ca.pub

В простой схеме без отдельного списка principals имя в сертификате должно соответствовать локальному пользователю. Для входа в общий технический аккаунт от нескольких персональных identities понадобится явная настройка AuthorizedPrincipalsFile или другого поддерживаемого механизма. Не расширяйте доверие ко всем именам ради устранения одной ошибки.

Проверьте конфигурацию и перезагрузите настройки службы. Для Ubuntu имя службы обычно ssh:

sudo sshd -t
sudo systemctl reload ssh

Если проверка вернула ошибку, сначала исправьте её. Дополнительные правила, включая списки отозванных ключей, описаны в руководстве sshd_config.

Проверяем вход и отказ

Пользователь подключается своим ключом и сертификатом:

ssh -i ~/.ssh/team_ed25519 \
  -o CertificateFile=~/.ssh/team_ed25519-cert.pub \
  alice@server.example.com

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

В тестовом аккаунте не добавляйте тот же обычный публичный ключ в authorized_keys: иначе клиент сможет войти им без сертификата. Для проверки ограничьте способы аутентификации параметрами IdentitiesOnly=yes и PreferredAuthentications=publickey, убедитесь по журналу, что использован именно сертификат. Сохранённый аварийный доступ проверяется отдельно.

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

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

Смотрите журнал сервера и диагностический вывод клиента, но не публикуйте их целиком без проверки. Технический ID выдачи помогает связать подключение с заявкой и конкретным человеком.

Срочный отзыв до окончания восьми часов

Короткий срок сокращает окно доступа, но не заменяет отзыв при потере устройства. OpenSSH поддерживает KRL — список отозванных ключей и сертификатов. Для учебного сертификата можно создать список:

ssh-keygen -k -f revoked.krl team_ed25519-cert.pub

Разместите проверенный KRL на серверах и настройте RevokedKeys на соответствующий файл. При следующих обновлениях списка сохраняйте прежние записи, используя предусмотренный режим обновления, а не каждый раз создавайте файл заново только с последним сертификатом.

Если настроенный файл RevokedKeys недоступен для чтения, OpenSSH отклоняет аутентификацию по публичным ключам; поэтому сначала разместите файл с правильными правами и только затем включайте настройку. Перед распространением проверьте список на тестовом узле. Доставляйте его атомарно и следите за доступностью файла. Ошибка распространения означает, что часть серверов продолжает принимать отозванный доступ.

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

Как превратить эксперимент в рабочий процесс

Опишите выдачу: кто подтверждает личность, кто согласует серверы и срок, как выбираются principals, где хранится журнал. Для отдельных задач можно выдавать более узкие разрешения и меньший срок, чем для обычного рабочего дня.

Сервис автоматической выдачи должен иметь собственную защиту, резервное восстановление и понятное поведение при отказе. Не раздавайте закрытый ключ CA нескольким скриптам, чтобы «всем было удобно». Чем меньше мест могут подписывать сертификаты, тем проще контролировать доверие.

После подтверждённого внедрения постепенно уберите ненужные постоянные ключи, сохранив согласованный аварийный доступ. В итоге вход на сервер становится разрешением с владельцем и сроком, а не строкой, которая пережила три ноутбука и давно забыла, зачем её добавили.