Подрядчик пропал, сервер остался: как перехватить контроль над машиной

MAATRIX

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

Три технических пути внутрь — и от чего зависит, какой сработает

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

1. Сброс пароля root через панель провайдера. Работает почти всегда на VPS: панель управляет гипервизором напрямую, ей не важно, что происходит внутри гостевой ОС. Нужен только доступ к самой панели.
2. Rescue-режим. Провайдер грузит сервер не со штатного диска, а с временного окружения по сети. Из него можно смонтировать диск и исправить что угодно внутри — включая случаи, где сброс пароля не помогает: диск зашифрован иначе, чем ожидалось, повреждена загрузочная запись, нужно посмотреть содержимое до полного включения сервера.
3. KVM/IPMI-консоль. Актуально в основном для выделенных серверов (bare metal), где нет гипервизора и кнопки сброса пароля в привычном смысле. Консоль показывает экран сервера с момента включения питания — как будто вы сидите перед монитором, — и позволяет зайти в BIOS, GRUB или single-user режим напрямую.

Какой путь доступен, зависит от типа сервера (VPS или выделенный) и от того, есть ли доступ к панели хостинга. Если панель недоступна тоже — это не тупик, но добавляет шаг с обращением в поддержку, разобранный ниже.

Сначала — тип сервера и провайдер, иначе план бессмыслен

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

whois <IP-адрес-сервера>

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

dig -x <IP-адрес-сервера> +short

Если в ней встречается что-то вроде *.hetzner.com, *.timeweb.ru, *.digitalocean.com — это прямое указание на провайдера. Отсутствие обратной записи тоже кое-что говорит: у части выделенных серверов и бюджетных VPS её не настраивают, и это скорее аргумент в пользу «выделенный сервер».

Косвенные признаки: у VPS почти всегда есть панель с разделом вроде «Reset password», «Console», «Rescue mode», а ресурсы (RAM, диск) заявлены округлёнными цифрами тарифной сетки. У выделенного сервера в характеристиках указана конкретная модель процессора и «некруглый» объём диска; у части бюджетных провайдеров панель ограничивается перезагрузкой и переустановкой ОС без сброса пароля и без KVM — тогда единственный путь внутрь без переустановки — обращение в поддержку за доступом к консоли.

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

Способ 1: сброс пароля root через панель хостинга

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

Порядок действий:

1. Зайдите в панель управления сервером у провайдера.
2. Найдите раздел управления конкретной машиной (обычно «Сервер» или «Instance») и в нём пункт вроде «Сбросить пароль root», «Reset root password» или «Reinstall password».
3. Задайте новый пароль. Действие применяется на уровне гипервизора: панель переписывает пароль внутри файловой системы сервера напрямую, без работающего SSH и согласия операционной системы.
4. Перезагрузите сервер через ту же панель и зайдите по SSH с логином root и новым паролем — либо, если провайдер поддерживает, сразу пропишите свой публичный SSH-ключ через тот же раздел вместо пароля.

Нюанс, который стоит проверить сразу после входа: не остался ли в /root/.ssh/authorized_keys ключ подрядчика. Сброс пароля root его не трогает — это два независимых механизма аутентификации, и старый ключ продолжит работать, даже если подрядчик заходил по ключу, а не по паролю. Просмотрите файл, сохраните его содержимое (пригодится ниже) и только потом решайте, какие записи оставлять.

Более детальный разбор этого способа, включая вариант с single-user режимом через GRUB для случаев без панели, — в статье «Сброс пароля root на VPS».

Способ 2: rescue-режим — когда простого сброса пароля мало

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

Общий порядок — детали интерфейса отличаются у провайдеров, но логика одна:

1. В панели найдите пункт «Rescue mode» / «Recovery mode» и включите его. Провайдер выдаст временный root-пароль для rescue-окружения — на экране панели или на email аккаунта.
2. Перезагрузите сервер — он загрузится не со своего диска, а с временного minimal-окружения провайдера.
3. Зайдите по SSH в rescue-окружение с выданным паролем.
4. Определите диск сервера и его разделы:

lsblk
fdisk -l

1. Смонтируйте основной раздел:

mount /dev/sda1 /mnt

Если на сервере использовался LVM, сначала активируйте группу томов:

vgscan
vgchange -ay
mount /dev/mapper/vg-root /mnt

1. Подготовьте окружение для chroot и войдите в систему сервера как будто она загружена:

mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

1. Внутри chroot вы — полноценный root смонтированной системы. Можно сбросить пароль (passwd root), добавить свой SSH-ключ в /root/.ssh/authorized_keys, посмотреть конфиги и /etc/passwd на посторонних пользователей, crontab -l — то же, что доступно изнутри загруженной ОС, но без риска, что штатные сервисы успеют отреагировать на внешний трафик, пока вы разбираетесь.
2. Выйдите из chroot (exit), размонтируйте всё в обратном порядке, выключите rescue-режим в панели и перезагрузите сервер обычным образом.

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

Способ 3: KVM/IPMI-консоль для выделенных серверов

На выделенном физическом сервере часто нет ни панели с кнопкой сброса пароля, ни rescue-образа в привычном облачном смысле — вместо этого есть встроенный в материнскую плату контроллер удалённого управления: IPMI у Supermicro, iDRAC у Dell, iLO у HPE. Это отдельный компьютер внутри сервера со своим сетевым интерфейсом, работающий независимо от основной ОС и даже от того, включён ли сервер вообще.

Через KVM/IPMI-консоль вы видите экран сервера с момента включения питания — POST, загрузчик, ядро — и управляете клавиатурой и мышью так, будто физически стоите перед машиной. Это открывает путь, недоступный через SSH: вход в BIOS, редактирование параметров загрузки в GRUB, загрузка в single-user режим.

Практический порядок для сброса пароля через single-user режим:

1. Подключитесь к KVM/IPMI-консоли из панели провайдера (обычно кнопка «Console» или «Remote console», открывающая Java- или HTML5-клиент в браузере).
2. Перезагрузите сервер и в момент появления меню GRUB остановите его (обычно Esc или Shift, зависит от таймаута и дистрибутива).
3. Выберите пункт загрузки, нажмите e для редактирования.
4. Найдите строку linux/linux16 и допишите в конец init=/bin/bash (или rd.break для дистрибутивов на базе RHEL с initramfs).
5. Загрузитесь с изменённым параметром (Ctrl+X или F10, зависит от версии GRUB).
6. Система загрузится в shell с правами root, минуя инициализацию и аутентификацию. Перемонтируйте корень в режим чтения-записи и сбросьте пароль:

mount -o remount,rw /
passwd root

1. Если система использует SELinux, после смены пароля выполните touch /.autorelabel, чтобы при следующей загрузке метки безопасности переиндексировались — иначе вход может заблокироваться уже по другой причине.
2. Перезагрузите сервер (exec /sbin/init или reboot -f из этого же shell) и зайдите по SSH с новым паролем.

Метод работает даже если провайдер вообще не предоставляет rescue-режим или сброс пароля отдельной услугой — важен только доступ к самой KVM/IPMI-консоли. Разбор технологии подробнее, включая различия между вендорами контроллеров, — в статье «KVM-доступ к серверу: зачем и как».

Если доступа к панели хостинга тоже нет

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

Специфика именно для технического доступа — когда цель не «стать владельцем аккаунта», а как можно быстрее попасть внутрь сервера, — в том, что стоит просить сразу, одним обращением:

• временный доступ к панели или разовый сброс её пароля, без обязательной смены владельца аккаунта, если это не критично прямо сейчас;
• включение rescue-режима на конкретном сервере с выдачей временных учётных данных;
• выдачу доступа к KVM/IPMI-консоли, если это выделенный сервер — часть провайдеров держит эту функцию отключённой по умолчанию и включает по отдельному запросу;
• информацию о состоянии сервера — включён ли он вообще, не заблокирован ли за неоплату (частая причина недоступности, которая маскируется под «сервер пропал» вместе с подрядчиком).

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

Что делать сразу после того, как зашли на сервер

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

Проверочный минимум сразу после входа:

• Ключи SSH. Просмотрите /root/.ssh/authorized_keys и аналогичные файлы у остальных пользователей с shell-доступом (cat /etc/passwd | grep -v nologin) — уберите записи, которые не можете однозначно опознать как свои.
• Пользователи системы. cat /etc/passwd и проверка sudo-группы (getent group sudo или wheel) — лишние учётные записи с правами администратора убираются в первую очередь.
• Cron-задачи. crontab -l -u root и содержимое /etc/cron.d/, /etc/cron.daily/ — иногда там остаются скрипты для скачивания обновлений или отправки данных без документации.
• Systemd-юниты. systemctl list-units --type=service --state=running — беглый просмотр списка на предмет того, что вы не узнаёте по названию.
• Секреты в конфигах. Пароли и токены в .env, docker-compose.yml, конфигах приложений, к которым имел доступ подрядчик, стоит считать скомпрометированными по умолчанию и сменить, а не проверять «на всякий случай».
• Файрвол. iptables -L -n или ufw status verbose — открытые порты, которых быть не должно, особенно к базе данных или админ-панелям без ограничения по IP.

После этого минимума заведите новую пару SSH-ключей и отключите вход по паролю в sshd_config (PasswordAuthentication no). А полноценный разбор — какие сервисы запущены, какой софт установлен, где данные и есть ли рабочие бэкапы — стоит провести по методологии из статьи «Достался чужой сервер без документации: с чего начинать разбор незнакомой машины»: вы формально «вошли», но по факту унаследовали недокументированную инфраструктуру, и разбираться в ней придётся с той же методичностью, как если бы её передали официально.

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