Резервный доступ к Linux-серверу: частые ошибки новичков

Если единственный SSH-ключ потеряется, а парольный вход на сервер отключён, вы рискуете потерять доступ к системе. На Ubuntu Server 24.04 резервный вариант — отдельная административная учётная запись с другим ключом и заранее проверенная консоль управления у хостера. Настройка займёт около 20–30 минут; главное правило — не закрывать текущую SSH-сессию, пока новый вход не проверен.

Что понадобится до начала

Инструкция рассчитана на Ubuntu Server 24.04 с установленным OpenSSH Server. Для других дистрибутивов могут отличаться имена службы и расположение настроек.

• Текущий SSH-доступ с правами sudo и открытая сессия, которую вы не будете закрывать до конца проверки.
• Доступ к панели хостинга и встроенной веб-консоли или serial console. Убедитесь, что умеете открыть её, пока сервер работает.
• Второй SSH-ключ, хранящийся отдельно от основного. Например, основной ключ — на рабочем ноутбуке, резервный — в защищённом менеджере секретов или на другом устройстве.
• Запись имени сервера, его IP-адреса и имени основной учётной записи. Не храните приватный ключ рядом с сервером.

Команды ниже выполняйте в текущей SSH-сессии, если не указано иное. Команды на своём компьютере выполняйте в отдельном терминале.

Настройка по шагам

1. Проверьте резервную консоль. Войдите в панель хостинга, откройте веб-консоль или serial console и убедитесь, что видите приглашение входа. Сам факт, что кнопка есть в панели, не доказывает, что консоль доступна именно вашему аккаунту. Проверка: вы можете открыть консоль и видите экран сервера. Не закрывайте текущую SSH-сессию. Если доступ к консоли требует отдельного пароля или настройки, выясните это сейчас.
2. Создайте отдельный ключ на втором устройстве. На резервном компьютере запустите команду ниже и задайте парольную фразу, если система её запросит. Если резервный ключ уже создан, не перезаписывайте его: команда может заменить существующие файлы. Проверка: появятся приватный файл ключа и файл с расширением .pub. На сервер копируется только содержимое публичного файла.

ssh-keygen -t ed25519 -f ~/.ssh/server_backup_ed25519 -C "server-backup-access"

1. Создайте резервную учётную запись. В текущей SSH-сессии замените backupadmin на выбранное уникальное имя. Не используйте его для повседневной работы. Команда попросит задать пароль учётной записи: задайте длинный случайный пароль и сохраните его в менеджере паролей. Пароль нужен как локальный резерв для входа через консоль, но позже SSH-вход по паролю будет отключён. Проверка: id backupadmin покажет новую учётную запись.

sudo adduser backupadmin
sudo usermod -aG sudo backupadmin
id backupadmin

Группа sudo даёт административные права. Поэтому резервная учётная запись должна быть защищена не слабее основной.

1. Установите публичный резервный ключ. На сервере создайте каталог и файл для ключа, затем задайте права доступа. Откройте файл публичного ключа на резервном компьютере, скопируйте всю строку и вставьте её вместо ВСТАВЬТЕ_СОДЕРЖИМОЕ_ФАЙЛА_PUB. Не вставляйте приватный ключ и не оставляйте строку-заглушку. Проверка: команда cat ниже выводит публичный ключ с комментарием, а права на каталог и файл равны 700 и 600.

sudo install -d -m 700 -o backupadmin -g backupadmin /home/backupadmin/.ssh
printf '%s\n' 'ВСТАВЬТЕ_СОДЕРЖИМОЕ_ФАЙЛА_PUB' | sudo tee /home/backupadmin/.ssh/authorized_keys > /dev/null
sudo chown backupadmin:backupadmin /home/backupadmin/.ssh/authorized_keys
sudo chmod 600 /home/backupadmin/.ssh/authorized_keys
sudo cat /home/backupadmin/.ssh/authorized_keys

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

1. Проверьте вход до изменения настроек SSH. На резервном компьютере откройте второй терминал. Подставьте адрес сервера и имя пользователя. Флаг -i указывает приватный ключ на вашем компьютере; этот файл никуда не загружайте. Проверка: команда подключает вас к серверу именно как backupadmin. Выполните sudo -v: команда должна запросить пароль этой учётной записи и завершиться без ошибки.

ssh -i ~/.ssh/server_backup_ed25519 backupadmin@АДРЕС_СЕРВЕРА

1. Отключите SSH-вход по паролю, только если ключевой вход проверен. Ubuntu читает дополнительные настройки из /etc/ssh/sshd_config.d/. Создайте отдельный файл с явными параметрами. Перед перезагрузкой проверьте синтаксис. Проверка: sshd -t завершается без вывода и кода ошибки; новая SSH-сессия с основным и резервным ключами открывается, а вход по паролю не проходит.

sudo tee /etc/ssh/sshd_config.d/00-local-access.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
EOF
sudo sshd -t
sudo systemctl reload ssh

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

Частые ошибки новичков

• Закрыть единственную сессию сразу после перезагрузки SSH. Если новая настройка мешает входу, исправить её через SSH уже не получится. Держите текущую сессию открытой, пока не проверите новый вход и консоль провайдера.
• Скопировать на сервер приватный ключ. Это секрет, который должен оставаться на клиентском устройстве. На сервер помещают только публичный ключ из файла .pub.
• Считать консоль провайдера эквивалентом SSH. Её доступность зависит от хостера, состояния виртуальной машины и прав в панели. Заранее проверьте вход, а не в день аварии.
• Отключить парольный вход до установки и проверки второго ключа. Ошибка в пути к ключу или правах на .ssh может лишить вас SSH-доступа. Сначала добейтесь входа с резервной учётной записью, затем меняйте настройки.
• Вставить ключ с переносами или неполной строкой. В таком случае OpenSSH может отвергнуть авторизацию. Файл authorized_keys должен содержать публичный ключ целиком, обычно одной строкой, а каталог и файл должны принадлежать нужному пользователю.

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

• Permission denied (publickey) — сервер не принял ключ. Проверьте имя пользователя, адрес сервера, соответствие приватного и публичного ключей, владельца и права на каталог .ssh и файл authorized_keys.
• Connection timed out — клиент не установил сетевое соединение. Проверьте IP-адрес, состояние сервера и правила сетевого экрана у хостера. Не меняйте SSH-порт наугад, если не знаете, где его разрешить.
• sudo: a password is required — команда sudo ждёт пароль учётной записи. Введите пароль, заданный при создании пользователя; символы при вводе могут не отображаться.
• Bad configuration option или сообщение об ошибке конфигурации — не перезагружайте службу повторно. Через текущую сессию исправьте файл и снова выполните sudo sshd -t. Перечитать конфигурацию можно только после успешной проверки.

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

Термин: break-glass-доступ — заранее подготовленный аварийный способ попасть в систему, когда обычный канал доступа не работает. В этой схеме это доступ через панель хостинга, а не постоянно включённый удалённый парольный вход.

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

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