Пароля root нет, есть только чужой ключ: как вернуть себе сервер

MAATRIX

Сервер достался вам без единого пароля — только приватный SSH-ключ, оставшийся от прежнего администратора. Root-пароль никто не знает, а в панель хостинга либо вообще нет входа, либо там нет консоли или rescue-режима. Это узкая, но частая ситуация: не «разберитесь в целом с наследством», а конкретная техническая задача — как через один-единственный ключ, который в любой момент может перестать работать, безопасно завести себе независимый доступ и забрать сервер под полный контроль, ничего при этом не сломав.

Сначала: не потеряйте единственный работающий вход

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

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

cp -a ~/.ssh/authorized_keys ~/.ssh/authorized_keys.bak-$(date +%Y%m%d)
cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-$(date +%Y%m%d)
sudo cp -a /etc/sudoers /etc/sudoers.bak-$(date +%Y%m%d) 2>/dev/null

• Скачайте копии этих файлов и себе на локальную машину (scp) — если сервер вдруг станет недоступен целиком, у вас останется хотя бы снимок конфигурации на момент, когда вы ещё могли зайти.
• Не трогайте firewall и правила SSH («на всякий случай ограничу порт», «закрою пароль по SSH») до того, как заведёте себе проверенный запасной вход. Каждое такое изменение — ещё один способ случайно захлопнуть дверь самому себе.

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

Что вообще позволяет этот ключ: sudo, root или ограниченный шелл

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

whoami
id
groups
cat ~/.ssh/authorized_keys   # посмотрите, нет ли ограничений на саму запись ключа

Обратите внимание на саму строку в authorized_keys, под которой вы зашли — если перед ключом стоит command="...", no-pty или restrict, вы получаете не полноценный интерактивный шелл, а строго ограниченный набор действий (иногда — единственную разрешённую команду). В этом случае дальнейшие шаги этой статьи могут быть просто невозможны через данный ключ, и путь только один — через хостинг-провайдера.

Если шелл интерактивный, проверьте права:

sudo -l          # покажет, что разрешено, даже если выполнить сразу не получится
sudo -n true && echo "sudo без пароля работает"

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

Создаём себе независимый доступ, не трогая чужой ключ

Если ключ даёт root или sudo без пароля — не спешите менять root-пароль или отзывать чужой ключ первым делом. Сначала закрепитесь: заведите себе полностью отдельную учётную запись с собственным новым SSH-ключом, оставив старый вход нетронутым как страховку.

Сгенерируйте новую пару ключей у себя локально — не переиспользуйте старые ключи, которые могли где-то засветиться:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_server-recovery -C "recovery-key-$(date +%Y%m%d)"

На сервере (из уже открытой сессии) создайте нового пользователя и выдайте ему sudo:

# Debian/Ubuntu
sudo adduser newadmin
sudo usermod -aG sudo newadmin

# RHEL/CentOS/Rocky/AlmaLinux
sudo useradd -m -s /bin/bash newadmin
sudo passwd newadmin
sudo usermod -aG wheel newadmin

Проверьте, что группа действительно даёт права в /etc/sudoers, а не осталась только формальностью:

sudo grep -E "^%sudo|^%wheel" /etc/sudoers
ls -la /etc/sudoers.d/

Пропишите ваш новый публичный ключ этому пользователю:

sudo mkdir -p /home/newadmin/.ssh
sudo cp ~/.ssh/id_ed25519_server-recovery.pub /home/newadmin/.ssh/authorized_keys
sudo chown -R newadmin:newadmin /home/newadmin/.ssh
sudo chmod 700 /home/newadmin/.ssh
sudo chmod 600 /home/newadmin/.ssh/authorized_keys

Пароль на новую учётку тоже стоит задать (sudo passwd newadmin) — как запасной вариант входа через консоль хостинга, если SSH вдруг откажет целиком, но не как основной способ входа: полагайтесь на ключ.

Проверяем новый доступ в отдельном окне, прежде чем что-то менять дальше

Это самый важный шаг всей процедуры, и его нельзя пропускать ради экономии времени. Откройте второе, независимое окно терминала — не разрывая первую сессию — и зайдите под новым пользователем и новым ключом:

ssh -i ~/.ssh/id_ed25519_server-recovery newadmin@ваш-сервер
sudo -i
id   # должно показать uid=0(root)

Только когда вторая сессия подтверждённо работает и sudo -i реально даёт root — можно двигаться дальше. Если что-то пошло не так, у вас всё ещё есть первая, рабочая сессия, чтобы это исправить.

Частая причина, почему новый вход не срабатывает, даже если всё сделано правильно, — ограничения в sshd_config:

grep -E "^AllowUsers|^AllowGroups|^DenyUsers|^DenyGroups" /etc/ssh/sshd_config

Если там явно перечислены конкретные логины, добавьте туда newadmin, проверьте синтаксис перед перезапуском и перезагрузите службу мягко, не разрывая существующие соединения:

sudo sshd -t && sudo systemctl reload ssh    # или sshd — имя службы зависит от дистрибутива

reload не разрывает уже установленные TCP-сессии, в отличие от резких вмешательств в firewall — это важно, если у вас в этот момент открыта единственная рабочая сессия.

Отзываем чужой ключ: без спешки и без сюрпризов

Только после того, как новый доступ проверен во втором окне и вы вошли под ним и получили root независимо от старого ключа, имеет смысл заниматься отзывом чужого доступа. Делайте это спокойно — бэкап уже снят на первом шаге, откатиться можно в любой момент.

Удаляйте не файл целиком, а конкретную строку — это снижает риск случайно стереть что-то ещё:

ssh-keygen -lf ~/.ssh/authorized_keys   # покажет отпечаток каждого ключа в файле построчно
grep -v "конкретный-отпечаток-или-фрагмент-ключа" ~/.ssh/authorized_keys.bak-* > ~/.ssh/authorized_keys

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

• authorized_keys у root, если вход по нему тоже возможен: /root/.ssh/authorized_keys.
• Нестандартный путь, если он задан отдельно: grep AuthorizedKeysFile /etc/ssh/sshd_config.
• AuthorizedKeysCommand — если ключи подтягиваются не из файла, а внешним скриптом (метаданные облака, LDAP, корпоративный сервис ключей), отзывать нужно на стороне источника, а не в файле на сервере — иначе ключ вернётся при следующей синхронизации.
• Ключи в authorized_keys других пользователей с shell-доступом — не только у того, чей ключ вы уже нашли: for u in $(awk -F: '$7 !~ /nologin|false/ {print $1}' /etc/passwd); do echo "== $u =="; sudo cat /home/$u/.ssh/authorized_keys 2>/dev/null; done.

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

crontab -u старый_логин -l 2>/dev/null
sudo systemctl list-units | grep -i старый_логин
ps aux | grep старый_логин

Если зависимостей не нашлось — на первом этапе безопаснее заблокировать учётную запись, а не удалять её сразу: sudo passwd -l старый_логин и sudo usermod -s /usr/sbin/nologin старый_логин. Удаление можно сделать позже, когда точно убедитесь, что ничего не сломалось. Параллельно поменяйте root-пароль на новый, даже если вы вошли через sudo, а не напрямую под root — если старый пароль вообще существовал и был кому-то известен, лучше не полагаться на то, что им никто не воспользуется.

Если хостинг не даёт rescue-доступ или консоль

Если ключ ведёт в тупик (обычный пользователь без sudo, или в authorized_keys стоит принудительная команда) — план из предыдущих разделов через SSH не сработает, и остаётся путь через провайдера. Но не у всех хостингов вообще есть встроенная консоль или rescue-режим, особенно у бюджетных VPS-тарифов, где такая функция может быть платной опцией, не включённой по умолчанию, либо отсутствовать в панели вовсе.

Порядок действий по убыванию простоты:

1. Спросите поддержку напрямую про сброс пароля root на их стороне. У многих провайдеров это можно сделать без консоли и без rescue-режима вообще — техподдержка сбрасывает пароль на сервере программно и присылает новый через панель или защищённым каналом. Это стоит попробовать в первую очередь, прежде чем разбираться с rescue.
2. Спросите про включение консоли/rescue как отдельной опции. Если по тарифу она не активна, часто её можно включить по запросу — иногда платно, иногда бесплатно, это зависит от провайдера и не стоит выдумывать заранее, во сколько это обойдётся именно у вас.
3. Если провайдер поддерживает снапшоты диска и создание нового сервера из снапшота — попросите снять снимок текущего диска и примонтировать его как дополнительный том к новому, временному серверу. Это позволяет отредактировать файлы (сбросить пароль через chroot, прочитать authorized_keys) оффлайн, вообще не завися от того, отвечает ли на команды исходный сервер.
4. Если ничего из этого недоступно, единственный формальный путь — обращение в поддержку с подтверждением, что аккаунт принадлежит вам: счета об оплате, реквизиты, привязанная карта. Это медленнее и не гарантирует сроков, но это единственный легитимный путь, если технических альтернатив нет. Более широкий разбор именно этой процедуры и того, что провайдеры обычно принимают как подтверждение владения, — в статье «Админ ушёл со всеми паролями: план возврата контроля», там же — пошаговая механика сброса root-пароля через VNC/IPMI, если консоль всё же появится. Сама процедура chroot и монтирования диска для сброса пароля root подробно разобрана в статье «Сброс пароля root на VPS».

Пока идёт переписка с поддержкой, берегите ключ, который у вас уже есть, как единственный рабочий канал — не экспериментируйте с ним, не пытайтесь через него менять конфигурацию SSH или firewall, чтобы не потерять и его тоже. Если параллельно у вас остаётся доступ хотя бы к части данных (файлы через SFTP, дамп базы, если он есть) — снимите резервную копию того, что критично, на случай, если восстановление через провайдера затянется и придётся поднимать сервис заново на новой машине.

Частые вопросы