MHOSTMHOST

Не могу подключиться по SSH

Если SSH на VPS MHost не пускает, причина почти всегда одна из немногих: сервер выключен, неверный адрес или порт, файрвол блокирует соединение, служба sshd не отвечает, IP забанен в fail2ban, либо не подходит пароль или ключ. В этой статье — чек-лист: как по тексту ошибки понять, что именно сломалось, и как это исправить, используя графическую консоль VMmanager 6, если сам SSH недоступен.

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

  • VPS MHost на Ubuntu 22.04/24.04, Debian 11/12 или AlmaLinux/Rocky Linux 8/9.
  • IP-адрес сервера и учётные данные — root или sudo-пользователь, пароль или SSH-ключ.
  • Доступ к панели VMmanager 6 — как запасной вариант: графическая консоль VNC в ней работает независимо от SSH и файрвола сервера, поэтому позволяет исправить проблему изнутри, даже если сам SSH недоступен. Если ещё не заходили в панель — см. «Как войти в VMmanager 6».

Шаг 1. Прочитайте текст ошибки — он подсказывает, где искать

SSH-клиент обычно не просто молчит при отказе — он называет причину, и она сразу сужает круг подозреваемых:

  • `Connection refused` (полная строка обычно выглядит как ssh: connect to host 185.246.66.12 port 22: Connection refused) — сервер ответил «здесь никто не слушает»: пакет дошёл, но подключение сразу отклонено. Обычно это значит, что служба sshd не запущена или слушает другой порт (Шаг 5); реже — что ваш IP только что забанен fail2ban (Шаг 6 — действие бана в fail2ban по умолчанию как раз отвечает отказом, а не тишиной) или сработало явное правило файрвола на отклонение. В любом случае сеть и IP-адрес точно в порядке — сервер вам ответил.
  • `Connection timed out` (ssh: connect to host 185.246.66.12 port 22: Connection timed out), либо подключение просто зависает без ответа — в отличие от «refused», сюда вообще ничего не вернулось. Обычно это файрвол молча отбрасывает пакеты — например, правило ufw по умолчанию (Шаг 4), — либо сервер выключен (Шаг 2), либо указан неверный IP-адрес (Шаг 3).
  • `Permission denied (publickey,password)` (или (publickey), если пароль отключён) — сеть, файрвол и sshd тут ни при чём: соединение уже установлено, sshd на связи, но он не принял ваши учётные данные. Разбирайтесь с логином, паролем или ключом (Шаг 7).
Совет: если сообщение непонятно или подключение просто зависает без объяснений, запустите ssh -v root@185.246.66.12 — флаг -v покажет, на каком именно шаге всё останавливается: до TCP-соединения, при согласовании протокола или уже на аутентификации. Для максимальной детализации есть -vvv.

Шаг 2. Убедитесь, что сервер вообще включён

  1. Войдите в панель VMmanager 6 — см. «Как войти в VMmanager 6».
  2. В списке виртуальных машин найдите свой сервер и посмотрите на его статус.
  3. Если сервер выключен — откройте меню «⋮» (три точки) рядом с ним и выберите «Запустить».
  4. Если сервер числится включённым, но не отвечает вообще ни на что — там же есть «Перезапустить».

📷 скриншот: список ВМ со статусом сервера и меню «⋮» с пунктами «Запустить»/«Перезапустить»

Проверьте: точный текст статуса и названия пунктов меню могут немного отличаться в зависимости от версии панели VMmanager 6 — ориентируйтесь на состояние «включён/выключен» и на меню «⋮» рядом с сервером.

Самая надёжная проверка — открыть графическую консоль VNC прямо в браузере: у неё нет отдельных требований к сети и файрволу сервера, так что если он загрузился, вы увидите его экран в любом случае. Подробный порядок действий — в статье «Консоль VNC и первое подключение (SSH/RDP)».

Готово: если в VNC видно приглашение на вход (login:) или рабочий стол — сервер точно включён и загрузился, а SSH стоит проверять дальше по шагам ниже. Если и VNC не открывается — обратитесь в поддержку Host, дело не в SSH.

Шаг 3. Проверьте IP-адрес, порт и имя пользователя

  • IP-адрес. Возьмите его из письма об активации сервера или со вкладки «IP-адреса» в карточке ВМ в VMmanager 6. После переустановки ОС адрес обычно остаётся прежним, но сверить не помешает — особенно если подключаетесь по старой заметке или сохранённому профилю в SSH-клиенте.
  • Порт. По умолчанию SSH слушает 22, и без флага -p клиент всегда пробует именно его. Если порт меняли (см. статью «Усиление SSH») — указывайте его явно: ssh -p 2222 root@185.246.66.12.
  • Имя пользователя. root подходит для свежего сервера. Если позже завели отдельного пользователя с sudo и ограничили root по SSH — подключайтесь именно под ним: ssh user@185.246.66.12, а не под root. Имя пользователя регистрозависимо.
Совет: старая запись в ~/.ssh/known_hosts от прежнего сервера с тем же IP-адресом — или от этого же сервера, но после переустановки ОС (он получает новый ключ хоста), — выдаёт пугающее предупреждение WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! и блокирует подключение. Это не ошибка доступа — просто обновите запись: ssh-keygen -R 185.246.66.12.

Шаг 4. Проверьте, не блокирует ли соединение файрвол

Если на Шаге 1 была ошибка timed out — начинайте отсюда: похоже, пакеты молча отбрасывает файрвол.

Ubuntu / Debian (ufw)

bash
sudo ufw status

Если в списке нет разрешающего правила для SSH — добавьте его:

bash
sudo ufw allow OpenSSH
Совет: OpenSSH — это профиль приложения на порт 22, который регистрирует пакет openssh-server (доступен на Ubuntu; на Debian такого профиля может не быть — используйте sudo ufw allow 22/tcp). Если вы меняли порт SSH на нестандартный, разрешайте именно его: sudo ufw allow 2222/tcp.

AlmaLinux / Rocky (firewalld)

bash
sudo firewall-cmd --state
sudo firewall-cmd --list-services

Если ssh нет среди разрешённых сервисов — добавьте:

bash
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Если меняли порт SSH — открывайте его отдельно, --add-service=ssh в этом случае не поможет:

bash
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
Важно: раз вы читаете эту статью, SSH и так недоступен — выполняйте команды этого шага через консоль VNC в VMmanager 6 (Шаг 2), а не пытайтесь сначала зайти по самому SSH.

Если статус файрвола — inactive (ufw) или not running (firewalld), он ни при чём — переходите к следующему шагу. Подробный разбор правил и логики ufw — в статье «Настройка файрвола UFW».

Шаг 5. Проверьте, что служба sshd вообще запущена

Если файрвол ни при чём, а на Шаге 1 была ошибка refused — скорее всего, дело в самой службе. Проверить и исправить это можно только изнутри сервера — через консоль VNC (Шаг 2), поскольку по SSH вы туда как раз попасть не можете.

Проверьте статус:

bash
# Ubuntu/Debian
systemctl status ssh

# AlmaLinux/Rocky Linux
systemctl status sshd

Если статус не active (running) — запустите службу и включите автозапуск:

bash
# Ubuntu/Debian
systemctl enable --now ssh

# AlmaLinux/Rocky Linux
systemctl enable --now sshd

Проверьте, на каком порту она реально слушает:

bash
ss -tlnp | grep ssh

Порт после двоеточия в выводе (например, 0.0.0.0:22) должен совпадать с тем, что вы указываете в ssh -p.

Если служба падает сразу после запуска — посмотрите лог:

bash
# Ubuntu/Debian
journalctl -u ssh -n 50 --no-pager

# AlmaLinux/Rocky Linux
journalctl -u sshd -n 50 --no-pager

Частая причина падения — синтаксическая ошибка в /etc/ssh/sshd_config после ручного редактирования; проверить конфигурацию без перезапуска можно командой sudo sshd -t (она же используется в статье «Усиление SSH»).

Готово: systemctl status показывает active (running), а ss -tlnp — sshd на нужном порту. Возвращайтесь к обычному SSH-клиенту на своём компьютере и пробуйте подключиться снова.

Шаг 6. Проверьте, не забанен ли ваш IP в fail2ban

Если недавно было несколько неудачных попыток входа подряд (например, вы сами ошиблись паролем, или к вашему IP-адресу через NAT привязаны другие устройства) — fail2ban мог забанить его автоматически.

Попасть на сервер, чтобы это проверить, можно через консоль VNC (Шаг 2) — она не идёт через сетевой стек и файрвол сервера, поэтому бан fail2ban на неё не действует. Либо подключитесь по SSH с другого IP-адреса (например, с мобильного интернета), если он у вас есть.

Проверьте статус jail'а sshd:

bash
sudo fail2ban-client status sshd

Если ваш IP есть в Banned IP list — снимите бан (замените 203.0.113.10 на свой адрес):

bash
sudo fail2ban-client set sshd unbanip 203.0.113.10
Совет: если fail2ban на сервере вообще не установлен — эту причину можно сразу исключить. Подробный разбор установки, настройки и разбана — в статье «Fail2ban: защита от брутфорса».

Шаг 7. Разберитесь с аутентификацией: ключ или пароль

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

  • `Permission denied (publickey,password)` — сервер принимает и ключ, и пароль, но ни один из тех, что вы предоставили, не подошёл.
  • `Permission denied (publickey)` — сервер принимает только ключ (пароль отключён — PasswordAuthentication no); без нужного ключа вход не получится, сколько бы раз вы ни вводили пароль.

Пароль. Убедитесь, что вводите пароль именно от учётной записи на сервере (root или ваш sudo-пользователь), а не пароль от панели VMmanager 6 или личного кабинета my.mhost.ee — это разные пароли. Забыли пароль root — смените его в VMmanager 6: карточка сервера → «⋮» → «Изменить пароль».

Не тот ключ. Если на компьютере несколько SSH-ключей, клиент может предложить не тот. Укажите нужный явно:

bash
ssh -i ~/.ssh/id_ed25519 root@185.246.66.12

Ключа нет на сервере. Через консоль VNC (Шаг 2) проверьте, что открытый ключ действительно записан на сервере:

bash
cat ~/.ssh/authorized_keys

Сверьте построчно с ключом на своём компьютере (cat ~/.ssh/id_ed25519.pub). Если нужной строки нет — допишите её (см. шаг 2 статьи «Усиление SSH» — там разобрано и через ssh-copy-id, и вручную).

Права доступа. SSH придирчив к правам на файлы — и на сервере, и на клиенте: ~/.ssh должен быть 700, authorized_keys — 600 на сервере, приватный ключ на своём компьютере — тоже 600. Слишком открытые права — частая причина молчаливого отказа именно по ключу:

bash
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Пароль отключён на сервере. Если рабочего ключа нет, а сервер отвечает Permission denied (publickey) без password в списке — вход по паролю на нём отключён (PasswordAuthentication no, см. статью «Усиление SSH») и не сработает, сколько угодно попыток. Временно верните его через консоль VNC (Шаг 2):

bash
sudo nano /etc/ssh/sshd_config

Найдите строку PasswordAuthentication no и замените на PasswordAuthentication yes, сохраните файл и перезапустите службу (команды — в Шаге 5 этой статьи). После этого зайдите по паролю и настройте ключ заново.

Важно: не забудьте вернуть PasswordAuthentication no обратно, когда ключ снова заработает, — иначе вы сводите на нет усиление SSH, сделанное ранее.
Готово: если один из пунктов подтвердился и вы его исправили — подключение должно пройти. Если нет — повторите Шаг 1 с флагом ssh -vvv, чтобы увидеть точное место отказа, и при необходимости обратитесь в поддержку Host.

Что дальше

Как только доступ восстановлен, стоит снизить риск повторения: настройте вход по ключу и отключите пароль — статья «Усиление SSH»; защитите порт файрволом, если этого ещё не сделали, — «Настройка файрвола UFW»; добавьте автоматический бан за перебор пароля — «Fail2ban: защита от брутфорса». Общий чек-лист по остальным базовым настройкам безопасности — в статье «Чеклист базовой защиты VPS».

Похожие статьи

ДалееСайт не открывается