Резервный доступ к серверу: безопасная настройка SSH

Потеря единственного SSH-ключа или блокировка основной учётной записи может остановить сервер так же быстро, как отказ диска. В этой инструкции для Ubuntu Server 24.04 LTS и OpenSSH 9.x вы создадите отдельного аварийного пользователя, установите для него независимый ключ, проверите вход в новой сессии и подготовите запасной канал через консоль провайдера. На настройку закладывайте 20–30 минут, включая обязательную проверку выхода из основного сеанса.

Что должно быть до начала

Нужен работающий SSH-доступ с правами sudo, локальный компьютер с клиентом OpenSSH и доступ к панели хостинга или облачного провайдера. Консоль провайдера называется по-разному: web console, serial console, VNC или rescue console. Это не замена SSH, а независимый путь на случай ошибки в конфигурации.

• Сервер на Ubuntu Server 24.04 LTS.
• OpenSSH Server версии 9.x. Точную версию можно проверить командой sshd -V; она выводится в поток ошибок.
• Локальный каталог для хранения второго закрытого ключа.
• Доступ к панели провайдера и права на создание пользователя на сервере.
• Зашифрованное офлайн-хранилище для резервного закрытого ключа. Не оставляйте единственную копию на ноутбуке.

Важно: не меняйте настройки SSH, пока не проверили новый вход в отдельном окне. Открытая текущая сессия — ваша страховка от опечатки в конфигурации.

Резервный доступ — это не второй файл с тем же ключом. Это отдельная учётная запись, отдельный закрытый ключ и независимый способ попасть на сервер.

Пошаговая настройка

1. Создайте отдельную учётную запись

Подключитесь к серверу основным способом и создайте пользователя breakglass. Такое имя не даёт дополнительных прав само по себе: безопасность обеспечивают ключ, права sudo и контроль хранения.

sudo adduser --disabled-password --gecos "" breakglass
sudo usermod --append --groups sudo breakglass
sudo passwd --lock breakglass

Команда passwd --lock блокирует парольную аутентификацию этой учётной записи, но не вход по SSH-ключу. Если в вашей системе политика запрещает группу sudo, используйте группу администраторов, принятую в вашей организации.

Проверка: выполните id breakglass. В выводе должна быть группа sudo, а команда getent passwd breakglass должна показать обычную домашнюю директорию и оболочку входа.

2. Выпустите отдельный ключ на локальном компьютере

Генерируйте ключ на своём компьютере, а не на сервере. Алгоритм Ed25519 поддерживается современными версиями OpenSSH и даёт компактную пару ключей.

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_breakglass -C "breakglass-ubuntu-2404"

На запрос о passphrase задайте длинную фразу. Закрытый файл id_ed25519_breakglass нельзя отправлять на сервер, в чат или в репозиторий. На сервер попадёт только файл с суффиксом .pub.

Проверка: убедитесь, что существуют два файла: ~/.ssh/id_ed25519_breakglass и ~/.ssh/id_ed25519_breakglass.pub. Закрытый ключ должен быть доступен только вам.

3. Установите открытый ключ пользователю

На сервере создайте каталог SSH и файл с разрешёнными ключами. Команды выполняйте в текущей рабочей SSH-сессии.

sudo install -d -m 700 -o breakglass -g breakglass /home/breakglass/.ssh
sudo touch /home/breakglass/.ssh/authorized_keys
sudo chown breakglass:breakglass /home/breakglass/.ssh/authorized_keys
sudo chmod 600 /home/breakglass/.ssh/authorized_keys

Откройте файл командой sudoedit /home/breakglass/.ssh/authorized_keys и вставьте одной строкой содержимое локального файла ~/.ssh/id_ed25519_breakglass.pub. Не переносите строку вручную и не вставляйте закрытый ключ.

При необходимости можно добавить перед ключом ограничители no-agent-forwarding,no-port-forwarding,no-X11-forwarding. Но не добавляйте restrict, если аварийной учётной записи понадобится полноценная диагностика через SSH.

Проверка: команда sudo ssh-keygen -lf /home/breakglass/.ssh/authorized_keys должна показать отпечаток добавленного ключа. Сравните его с выводом ssh-keygen -lf ~/.ssh/id_ed25519_breakglass.pub на локальном компьютере.

4. Проверьте вход до любых изменений в sshd

Откройте новое окно терминала и подключитесь по адресу сервера, явно указав новый ключ.

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_breakglass breakglass@SERVER_IP

Замените SERVER_IP на адрес своего сервера. После входа проверьте права, но не выполняйте опасные команды ради теста:

whoami
hostname
sudo -v
sudo id

Проверка: whoami должен вывести breakglass, а sudo id — идентификатор uid=0(root). Основная SSH-сессия при этом должна оставаться открытой.

5. Проверьте независимость резервного пути

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

Заранее войдите в панель провайдера и найдите консоль сервера. Не нужно отключать SSH: задача проверки — убедиться, что вы знаете путь, а не создавать аварию.

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

6. Зафиксируйте порядок восстановления

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

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

Что не стоит менять вслепую

После успешной проверки можно отдельно усилить SSH, но эти изменения не относятся непосредственно к созданию резервного доступа. Не отключайте PasswordAuthentication, не запрещайте root и не добавляйте глобальный AllowUsers, пока не проверили, что новый пользователь входит и получает нужные права. Каждая такая настройка может закрыть рабочий или резервный путь.

Для проверки конфигурации перед перезагрузкой используйте:

sudo sshd -t

Если команда не вывела ошибок, это означает только корректный синтаксис. Она не доказывает, что вы сможете войти именно тем ключом и с нужного адреса.

Если не получилось

«Permission denied (publickey)»

Чаще всего клиент использует не тот ключ, ключ вставлен с переносом или у каталога неверные права. Подключитесь с -o IdentitiesOnly=yes, проверьте отпечатки и выполните namei -l /home/breakglass/.ssh/authorized_keys. Для каталога .ssh нужны права 700, для authorized_keys — 600.

«sudo: a terminal is required»

Такое сообщение появляется, если команда выполняется в неинтерактивном канале, а политика sudo требует терминал. Войдите обычным SSH-клиентом в резервную учётную запись и повторите команду. Не отключайте требование к терминалу только ради теста.

«Connection timed out»

Проблема может быть в firewall, сетевой ACL или неверном адресе, а не в ключе. Проверьте, что порт SSH открыт для вашей сети и что сервер отвечает через панель провайдера. Если веб-консоль доступна, посмотрите системные журналы и статус службы SSH.

sshd не перезапускается после изменения конфигурации

Не закрывайте действующую сессию. Выполните sudo sshd -t, исправьте строку, на которую указывает ошибка, и используйте перечитывание конфигурации только после успешной проверки. При потере SSH применяйте консоль провайдера, а не пытайтесь многократно угадывать синтаксис.

Где подход ломается

Отдельный ключ не поможет, если провайдер заблокировал аккаунт, сервер выключен, дисковая система повреждена или сеть полностью недоступна. В этих случаях нужен не второй SSH-пользователь, а консоль, rescue-режим или процедура восстановления из резервной копии. Это отдельная тема: здесь рассматривается именно безопасный аварийный вход на работающий сервер.

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

Что делать дальше

Поставьте в календарь проверку раз в квартал: войдите новым ключом, проверьте sudo, доступность консоли и возможность получить ключ из офлайн-хранилища. После проверки изучите журнал аутентификации и убедитесь, что резервный вход не используется в обычной работе. Отдельно измеряйте время восстановления доступа — от обнаружения проблемы до успешного входа на сервер. Именно этот показатель показывает, работает ли план, а не просто существует ли файл с ключом.

Сноска. Break-glass access — аварийный доступ, который используют при отказе штатного способа входа. Название отсылает к стеклу с молотком: такой путь не должен быть удобным ежедневным каналом.