Сервер недоступен по SSH: что делать

MAATRIX

Подключение по SSH внезапно перестало работать, и терминал висит на «connecting» или отвечает «Connection refused». Не паникуйте: в большинстве случаев сервер жив, а проблема локализуется за пару минут. Ниже — порядок действий от быстрой проверки до входа в обход SSH через консоль провайдера, с командами под каждый случай.

Первое действие: локализуем проблему

Прежде чем что-то менять, поймите, на чьей стороне сбой. Сначала проверьте, отвечает ли сервер вообще, обычным пингом с вашей машины:

ping -c 4 ВАШ_IP

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

nc -vz ВАШ_IP 22

Ответ «succeeded» означает, что порт открыт и слушается, а значит причина в аутентификации или конфигурации SSH. «Connection refused» говорит, что порт закрыт или демон не запущен. «Timed out» — почти всегда файрвол молча отбрасывает пакеты. Уже по этим двум командам вы сузили круг причин вдвое, и дальше действуете прицельно, а не наугад.

Проблема на вашей стороне

Часто виновата вовсе не серверная часть. Самое частое — сменившийся ключ хоста после переустановки системы: SSH предупреждает о возможной подмене и отказывается соединяться. Лечится удалением старой записи:

ssh-keygen -R ВАШ_IP

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

ssh -v -p 22 user@ВАШ_IP

Подробный лог показывает, доходит ли дело до обмена ключами, предлагается ли аутентификация и где именно происходит отказ. Это экономит массу времени: вы видите не абстрактное «не подключается», а конкретный этап, на котором рвётся соединение, и понимаете, копать в сторону ключа, пароля или сети.

Порт открыт, но вход не проходит

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

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

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

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

Вход в обход SSH через консоль провайдера

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

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

systemctl status ssh
journalctl -u ssh --no-pager | tail -20

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

Частые причины и как их устранить

Разберём типовые случаи, которые вы, скорее всего, увидите через консоль. Первый — файрвол заблокировал порт SSH, часто после неаккуратной настройки ufw. Проверьте правила и при необходимости откройте порт:

ufw status
ufw allow 22/tcp

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

df -h

Третий случай — упавший или незапущенный демон sshd, часто из-за ошибки в конфигурации. Проверьте конфиг на синтаксис и перезапустите службу:

sshd -t
systemctl restart ssh

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

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

Когда виновата сеть или сам сервер

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

Если и это не помогает, стоит проверить статус самого провайдера: возможно, идут работы в дата-центре или авария на его стороне. Надёжный хостер уведомляет о таком заранее и держит связь. Регулярные необъяснимые пропадания сервера — тревожный сигнал и повод задуматься о переезде к провайдеру со стабильной сетью и внятной поддержкой.

Профилактика: как не потерять доступ снова

Большинство блокировок по SSH — результат собственных действий, и их легко предупредить. Главное правило: меняя настройки файрвола или sshd, всегда держите открытой вторую сессию, чтобы откатить изменения, если новое правило отрезало вам доступ. Не выходите из рабочего подключения, пока не убедились, что новое соединение устанавливается.

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

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