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

Сначала определите, что именно сломано

Фраза «не могу войти» покрывает два совершенно разных сбоя, и ремонт зависит от того, какой из них у вас. Разберитесь со своей машины, прежде чем что-либо менять на сервере.

Шаг 1: отвечает ли что-нибудь на порту SSH? Команда nc проверяет TCP-порт, не отправляя данных. В руководстве OpenBSD -z означает «только проверять наличие слушающих процессов, не отправляя им данных», -v включает подробный вывод, а -w задаёт тайм-аут в секундах.

nc -vz -w 5 203.0.113.10 22

Подставьте свой адрес и свой порт SSH. Возможны три исхода:

• Команда сообщает об успехе. Сетевой путь открыт, и кто-то слушает порт. Проблема в аутентификации или в правиле, которое применяется после соединения (ключи, права, AllowUsers, PAM). Переходите к соответствующим разделам.
• «Connection refused». Кто-то ответил, но соединение не принял. Типичные причины: sshd не запущен, sshd слушает не тот порт, к которому вы обращаетесь, либо фаервол отвечает отказом, а не молча отбрасывает пакеты.
• Команда зависает до тайм-аута. Никто не ответил. Документация Nmap описывает «фильтруемый» порт как порт, пробы к которому останавливает фильтрация пакетов, и отмечает, что фильтры, просто отбрасывающие пробы без ответа, встречаются гораздо чаще, чем возвращающие ошибки. Поэтому тайм-аут чаще всего указывает на фаервол (на сервере или перед ним), неверный адрес или выключенный сервер.

Обратите внимание, что ключи nc различаются между реализациями. Приведённые выше взяты из версии OpenBSD; если ваша их не принимает, смотрите её страницу руководства.

Шаг 2: если порт открыт, спросите у ssh, что происходит. Вынесите параметры подключения в блок Host в ~/.ssh/config: так не нужно каждый раз набирать пользователя и адрес, а порт позже меняется в одном месте:

Host myserver
    HostName 203.0.113.10
    User deploy
    Port 22

ssh -v -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes myserver

В руководстве по ssh сказано, что -v выводит отладочные сообщения о ходе работы, а повторение ключа увеличивает подробность, максимум до трёх раз. IdentitiesOnly ограничивает ssh указанным вами ключом вместо всех, что хранит агент. Найдите в выводе место, где всё останавливается: до установки соединения, при обмене ключами или на шаге аутентификации.

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

Шаг 4: когда появилась консоль, смотрите на сервер. Проверьте службу, что реально слушается, и свежий журнал:

sudo systemctl status ssh
sudo ss -tlnp | grep sshd
sudo journalctl -u ssh -e

В некоторых дистрибутивах служба называется sshd. Команда ss -tlnp показывает слушающие TCP-сокеты с числовыми портами и владеющим процессом, так что видно, привязан ли sshd к ожидаемому порту. journalctl -u ssh -e переходит в конец журнала этой службы. В семействе Debian журнал аутентификации может лежать и в /var/log/auth.log. Журнал самого сервера обычно называет причину отказа.

Запасные входы, по порядку

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

1. Веб-консоль или VNC-консоль. Даёт приглашение для входа на виртуальном экране сервера, поэтому работает даже при сломанных сетевых правилах или sshd. Нужна локальная учётная запись с паролем. Если ни у одной из ваших учётных записей нет локального пароля, консоль может вас не пустить; тогда нужен режим восстановления или способ сброса доступа, описанный у провайдера.
2. Режим восстановления (rescue). Сервер загружает временную систему, и вы работаете со своим диском оттуда. Это подходящий инструмент, если установленная система не загружается или в консоли вообще нельзя войти.
3. Подключение диска к другому серверу. Если провайдер это поддерживает, диск сломанного сервера подключают ко второму серверу, монтируют и правят файлы напрямую. Идея та же, что и у rescue-режима, только на системе, которую вы контролируете.
4. Восстановление снимка или резервной копии. Это крайняя мера, потому что она отбрасывает всё, что записано после снимка. Если возможно, сделайте свежий снимок перед восстановлением, чтобы не потерять данные. Проверенная резервная копия делает этот вариант безопасным: см. руководство по резервному копированию 3-2-1.

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

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

lsblk -f
sudo mount /dev/ВАШ_КОРНЕВОЙ_РАЗДЕЛ /mnt
sudo cp -a /mnt/etc/ssh/sshd_config /mnt/etc/ssh/sshd_config.broken
sudo nano /mnt/etc/ssh/sshd_config
sudo umount /mnt

lsblk -f выводит блочные устройства с файловыми системами, а mount подключает файловую систему с устройства к дереву каталогов. cp -a копирует с сохранением атрибутов, так что оригинал останется до правки. Чтобы выполнять команды как в настоящей системе, sudo chroot /mnt запускает оболочку с корнем в /mnt, и путь вроде /etc/ssh разрешается внутри вашей системы. Это помогает с путями в Include и с sshd -t. Если в rescue-окружении не хватает чего-то нужного sshd и ошибка относится к окружению, а не к вашему конфигу, проверьте конфигурацию после первой нормальной загрузки, уже из консоли.

Исправляем сломанный sshd_config

Из консоли сначала проверьте конфигурацию. В руководстве по sshd ключ -t описан как тестовый режим: он только проверяет корректность файла конфигурации и целостность ключей.

sudo sshd -t

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

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.broken
sudo cp -a /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl reload ssh

Если после перезапуска sshd остался остановленным, reload перечитывать нечего, поэтому используйте sudo systemctl start ssh и проверьте systemctl status ssh. Помните, что служба может называться sshd. Сам файл описан в нашем справочнике по sshd_config.

Изменённая вами настройка может быть переопределена. В руководстве по sshd_config сказано, что для каждого ключевого слова используется первое полученное значение. Директива Include принимает шаблоны, обрабатывает совпадения в лексикографическом порядке, а относительные пути ищет в /etc/ssh. В некоторых дистрибутивах в начале основного файла стоит строка Include для каталога /etc/ssh/sshd_config.d/, поэтому значение из подключённого файла может перебить то, что вы написали ниже. Так «я отключил вход по паролю» незаметно не срабатывает, а забытый файл в этом каталоге способен лишить вас доступа, когда вы считали основной файл единственным источником. Найдите все места, где задано ключевое слово, и спросите у sshd итоговый результат:

grep -n '^Include' /etc/ssh/sshd_config
sudo grep -rniE 'passwordauthentication|permitrootlogin|allowusers|port|listenaddress' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/
sudo sshd -T | grep -iE '^(passwordauthentication|permitrootlogin|allowusers|port|listenaddress) '

Ключ -T выводит действующую конфигурацию и выполняет дополнительные проверки -t. Чтобы увидеть, как блоки Match применяются к конкретному соединению, добавьте описание соединения через -C, например sudo sshd -T -C user=deploy,addr=198.51.100.7,host=server. Без -C у sshd нет данных о соединении, с которыми можно сопоставить блоки.

В выводе стоит перепроверить две настройки: Port и ListenAddress. Если sshd теперь слушает порт, который вы не открыли, или только адрес, до которого вы не дотягиваетесь, соединения будут отклоняться, хотя служба запущена. В руководстве указано, что Port по умолчанию равен 22, а без ListenAddress sshd слушает все локальные адреса. Измените тот файл, значение из которого действует, выполните sshd -t, перечитайте конфигурацию и держите консоль открытой, пока новое соединение не заработает.

Исправляем фаервол, блокирующий SSH

Если nc ушёл в тайм-аут или получил отказ, а sshd работает и слушает порт, следующий подозреваемый фаервол. Такое часто случается после включения фаервола без разрешения SSH, после переноса sshd на новый порт без его открытия или после ограничения SSH адресом, который потом сменился. Как соотносятся ufw, nftables и iptables, объясняет наше руководство по фаерволу Linux. Из консоли посмотрите, что действует прямо сейчас.

ufw. В руководстве по ufw описан status numbered для нумерованного списка правил. Затем разрешите порт, которым действительно пользуетесь:

sudo ufw status verbose
sudo ufw status numbered
sudo ufw allow 22/tcp
sudo ufw status numbered

Если вы перенесли SSH, разрешайте тот порт (например, sudo ufw allow 2222/tcp). Если вы ограничили SSH одним адресом источника, а ваш адрес сменился, добавьте правило для нового, используя полный синтаксис из руководства:

sudo ufw allow proto tcp from 198.51.100.7 to any port 22

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

sudo ufw status numbered
sudo ufw delete 3

В руководстве сказано, что --dry-run показывает изменения, ничего не меняя, это удобно для команды, в которой вы не уверены. Как аварийная мера, sudo ufw disable выгружает фаервол и отключает его при загрузке. Это снимает всю защиту, поэтому используйте только чтобы вернуться на сервер, затем исправьте правила и снова выполните sudo ufw enable. В том же руководстве отмечено, что ufw задаёт вопрос при включении фаервола в сессии ssh, а включение может разорвать существующие соединения, например ssh. Правило для SSH, добавленное заранее, этого избегает. См. также наш справочник по ufw.

nftables. Выведите набор правил с дескрипторами (handle), затем вставьте правило accept в начало или удалите мешающее правило по его дескриптору, как показано в вики nftables:

sudo nft -a list ruleset
sudo nft insert rule inet filter input tcp dport 22 accept
sudo nft delete rule inet filter input handle 7

Подставьте семейство, таблицу и цепочку из вашего вывода, потому что inet filter input это лишь схема из нашего руководства. Если правила сохранены в файл, загружаемый при старте, например /etc/nftables.conf, исправьте и файл, иначе блокировка вернётся после следующей перезагрузки.

iptables. По руководству iptables, -S выводит правила цепочки, -L с -n -v --line-numbers перечисляет их в числовом виде с номерами позиций, -I вставляет правило в заданную позицию, а -D удаляет по номеру:

sudo iptables -S INPUT
sudo iptables -L INPUT -n -v --line-numbers
sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
sudo iptables -D INPUT 4

В iptables важен порядок, поэтому правило accept ставится в позицию 1, а не в конец за запрещающим правилом. Удаляйте по номеру только после свежего вывода списка. Когда соединение восстановится, проверьте его из нового терминала, а затем сохраните правильные правила тем способом, которым ваш сервер загружает их при старте.

Ключи, права, AllowUsers и вход по паролю

Если nc отработал успешно, а ssh сообщает, что вход не принят, причина обычно в одном из четырёх пунктов ниже. Со стороны ключей подробнее разбирает наше руководство по ошибке Permission denied (publickey).

Неверные права на ~/.ssh. В руководстве sshd сказано, что если authorized_keys, каталог ~/.ssh или домашний каталог доступны на запись другим пользователям, файл могут изменить или подменить, и sshd не станет его использовать, если только StrictModes не установлен в no. В руководстве sshd_config StrictModes описан как проверка режимов и владельцев файлов пользователя и его домашнего каталога перед разрешением входа, и по умолчанию он включён. Осмотрите весь путь и исправьте:

namei -l /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chown -R deploy:deploy /home/deploy/.ssh

namei -l показывает владельца и права каждого компонента пути, поэтому каталог, доступный на запись не тому, сразу заметен. Не отключайте StrictModes ради быстрого результата. Рекомендуемые в руководстве права для authorized_keys: чтение и запись для пользователя и ничего для остальных, то же и для каталога. См. справочник по authorized_keys.

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

sudo sshd -T -C user=deploy,addr=198.51.100.7,host=server | grep -iE '^(allowusers|denyusers|allowgroups|denygroups) '

Если вашего имени нет, добавьте его (или уберите ограничение), выполните sshd -t и перечитайте конфигурацию. Синтаксис шаблонов объясняет справочник по AllowUsers.

Вход по паролю отключён, а рабочего ключа нет. Это классический итог установки PasswordAuthentication в no до проверки ключа. По руководству, PasswordAuthentication по умолчанию равен yes, а PermitRootLogin по умолчанию равен prohibit-password, что отключает для root вход по паролю и keyboard-interactive. То есть у root по SSH паролей по умолчанию и не было. Из консоли есть два выхода. Более чистый: положить ваш открытый ключ туда, откуда его прочитает sshd. На своей машине ssh-keygen -y -f ~/.ssh/id_ed25519 читает файл закрытого ключа и выводит соответствующий открытый, который затем добавляют в authorized_keys пользователя с правами, описанными выше. Временный: вернуть вход по паролю в том файле, значение из которого действует, проверить, перечитать конфигурацию, войти, правильно установить ключ и снова отключить пароль. Не оставляйте его включённым. Если значение задаёт отдельный файл в каталоге с фрагментами, меняйте именно его.

Сама схема только с ключами описана в нашем руководстве по укреплению SSH. Когда вход по ключу заработает из нового терминала, снова отключите аутентификацию по паролю.

Ошибки настройки TOTP и PAM

Двухфакторная аутентификация через PAM проще всего приводит к потере доступа, потому что сбой возникает в файле вне sshd_config. Настройка описана в нашем руководстве по двухфакторной аутентификации SSH, там же свой порядок внедрения. Здесь сторона восстановления.

Типичные симптомы: ключ принят, затем запрашивается код, который ничем не принимается, или пользователь так и не выполнил команду регистрации. Модуль TOTP читает секрет пользователя из домашнего каталога, поэтому пользователь без него получает отказ, если не указана опция nullok. В документации модуля nullok описан как позволяющий входить без кода тем, кто его ещё не настроил.

Исправляйте в таком порядке, от наименее инвазивного к наиболее:

1. Вернитесь к входу только по ключу в sshd_config. Ключевое слово AuthenticationMethods принимает списки через запятую, и в руководстве сказано, что успешная аутентификация требует пройти все методы хотя бы одного списка. Если задано publickey,keyboard-interactive, верните publickey, выполните sudo sshd -t и перечитайте конфигурацию. PAM при этом не затрагивается, и вы получаете тот вход, который был до изменений.
2. Или временно пустите незарегистрированных. Добавьте nullok в строку модуля, пусть каждый пользователь выполнит команду регистрации, затем уберите nullok.
3. Крайняя мера: закомментировать строку PAM. В PAM строки, начинающиеся с #, являются комментариями, как указано в руководстве pam.d. Откройте файл службы, обычно /etc/pam.d/sshd, и поставьте # перед строкой, подключающей pam_google_authenticator.so.

Оговорка к последнему варианту: вы только что убрали второй фактор, и в зависимости от того, что ещё подключает файл, вход теперь может запрашивать пароль. В руководстве sshd_config также предупреждается, что при включённом UsePAM следует отключить либо PasswordAuthentication, либо KbdInteractiveAuthentication, поскольку вход keyboard-interactive через PAM обычно играет ту же роль, что и пароль. Считайте закомментированную строку временным мостом: верните строку после регистрации и проверьте вход из второго терминала, не закрывая консоль. Не правьте файл PAM, если от него зависит ваша единственная сессия. Если код не подходит даже зарегистрированному пользователю, проверьте часы сервера: коды по времени зависят от них. Храните выданные резервные коды офлайн.

Блокировка fail2ban и предупреждение о ключе хоста

fail2ban заблокировал ваш собственный адрес. После нескольких неудачных попыток, например пока вы чинили ключ, fail2ban мог заблокировать ваш адрес в фаерволе. Из консоли (или из другой, не заблокированной сети) посмотрите джейл и снимите блокировку. Каждая команда описана в руководстве по fail2ban-client:

sudo fail2ban-client status
sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 198.51.100.7

status показывает состояние сервера, а с именем джейла ещё и заблокированные в нём адреса. set JAIL unbanip IP снимает блокировку в этом джейле. unban IP снимает её во всех джейлах и в базе, а unban --all очищает всё, что редко нужно на сервере, который постоянно сканируют. Чтобы не повторилось, добавьте свой постоянный адрес или выходной адрес VPN в ignoreip в конфигурации джейла. В руководстве по jail.conf это список адресов, которые не блокировать, допускается и маска CIDR. Клиент умеет добавить адрес и на лету через set JAIL addignoreip IP, но запишите его в конфигурацию, чтобы он сохранился. Будьте внимательны: игнорируемый адрес, доступный злоумышленнику, например общая сеть офиса, ослабляет защиту. Настройка описана в нашем руководстве по fail2ban, а если непонятно, почему блокировка была или не была, см. fail2ban не блокирует и защиту SSH от перебора.

«Remote host identification has changed» не потеря доступа. Это предупреждение выдаёт ваш компьютер. В руководстве ssh сказано, что при смене идентификатора хоста ssh предупреждает и отключает аутентификацию по паролю, защищаясь от подмены и атаки «человек посередине», а StrictHostKeyChecking определяет поведение для хостов с изменившимся ключом. Обычно оно появляется после пересборки или переустановки сервера или при работе в rescue-системе с другим ключом. Не обходите его вслепую. Сначала сравните отпечаток. В консоли сервера хеш по умолчанию для ssh-keygen -l это SHA256:

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

Если он совпадает с тем, что показывает клиент, удалите устаревшую запись на своём компьютере и подключитесь снова. Ключ -R у ssh-keygen удаляет все ключи для имени хоста из файла known_hosts, порт при необходимости записывается как [host]:port:

ssh-keygen -R 203.0.113.10
ssh-keygen -R "[203.0.113.10]:2222"

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

Как менять SSH и не потерять доступ

Большинства потерь доступа можно избежать, если соблюдать порядок. В руководстве по двухфакторной аутентификации есть свой порядок внедрения; этот раздел согласуется с ним и добавляет несколько мер.

1. Держите вторую сессию открытой на всё время изменения. Не закрывайте рабочую, пока новая не заработала.
2. Сделайте резервную копию конфига перед правкой: sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak. Не забывайте и про файлы в /etc/ssh/sshd_config.d/.
3. Проверяйте до применения. sudo sshd -t ловит синтаксические ошибки, а sudo sshd -T показывает, что реально будет действовать.
4. Используйте reload, а не restart. В руководстве sshd сказано, что sshd перечитывает конфигурацию по сигналу SIGHUP, заново запуская себя с теми же параметрами. На уровне службы это sudo systemctl reload ssh (в некоторых системах служба называется sshd). Reload не заменяет вторую сессию, а лишь избавляет от паузы при перезапуске службы.
5. Проверяйте из нового терминала командой ssh -o ConnectTimeout=10 myserver. В руководстве ssh_config ConnectTimeout описан как тайм-аут в секундах, так что закрытый порт даёт быструю ошибку, а не зависание.
6. Запланируйте откат, если изменение может отрезать вас от сервера, например правило фаервола или смена аутентификации. Команда at выполняет команду позже. По её руководству она читает команды со стандартного ввода или из файла, выполняет их через /bin/sh, принимает время вида now + 10 minutes, показывает задания через atq и удаляет через atrm.
7. Держите ссылку на консоль под рукой и заранее войдите в неё один раз, чтобы убедиться, что учётные данные работают.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
echo 'cp -a /etc/ssh/sshd_config.bak /etc/ssh/sshd_config; systemctl reload ssh' | sudo at now + 10 minutes
sudo atq
# ... вносим изменение, sudo sshd -t, reload, проверяем из нового терминала ...
sudo atrm НОМЕР_ЗАДАНИЯ

Если вы проверяете изменение фаервола, безопасный откат для ufw это echo 'ufw disable' | sudo at now + 5 minutes, который, как описано выше, снимает защиту, пока вы не исправите правила. Отмените задание через atrm, когда убедитесь, что новые правила работают. Если команда at не установлена, установите её из дистрибутива до изменения, а не во время. Поскольку задание срабатывает по таймеру, оно может отменить и то изменение, которое вы ещё проверяете, поэтому задавайте запас времени и смотрите atq. Прочитайте руководство по at для вашей системы, так как детали различаются между реализациями.

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

Когда обращаться за помощью

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

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

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