SSH Connection refused: почему сервер отклоняет подключение

Сообщение ssh: connect to host ... port ...: Connection refused означает, что компьютер дошёл до указанного IP-адреса, но TCP-соединение с выбранным портом было отклонено. Обычно SSH-служба не запущена, слушает другой порт или принимает соединения только на другом адресе. Реже отказ формирует firewall.

Пароль и SSH-ключ здесь ещё не проверялись. Если сервер запрашивает пароль, а затем пишет Permission denied, соединение уже установлено и нужна другая диагностика.

Сначала запишите точный адрес и порт

Обычная команда ssh admin@example.com подключается к порту 22. Если в конфигурации сервера SSH перенесён, порт указывают ключом -p:

ssh -p 2222 admin@203.0.113.10

В примере admin — имя пользователя, 203.0.113.10 — тестовый адрес из диапазона документации, а 2222 — нестандартный порт. Замените все три значения реальными. Сам по себе другой порт не защищает от целевой атаки; он лишь сокращает часть автоматического шума.

Проверьте данные в панели хостера или в сохранённой конфигурации, а не перебирайте порты. У доменного имени мог измениться IP, а после переустановки VPS старый адрес мог перейти другому серверу. Сопоставить домен и адрес поможет руководство по диагностике DNS.

Отличите отказ от таймаута и ошибки имени

Текст ошибки сокращает список причин:

Сообщение	Что уже известно
Could not resolve hostname	имя не преобразовалось в IP-адрес
Connection timed out	ответ не пришёл: возможны маршрут, выключенный узел или молча блокирующий firewall
No route to host	система не нашла маршрут либо получила сетевой запрет
Connection refused	адрес ответил отказом на выбранном порту
Permission denied	SSH-служба ответила, но не приняла способ входа
Host key verification failed	сервер ответил, но его ключ не совпал с ожидаемым

Не удаляйте запись из known_hosts при Connection refused: проверка ключа сервера ещё не началась. И не меняйте пароль — он также не участвовал в соединении.

Проверьте порт со своего компьютера

На Linux или macOS можно запросить подробный журнал клиента. Запускайте команду на компьютере, с которого обычно входите; она только делает попытку подключения и печатает этапы соединения:

ssh -vvv -p 22 admin@SERVER_IP

Замените пользователя и адрес. Ключ -vvv включает подробный вывод и ничего не меняет на сервере. Последние строки покажут фактический IP и порт. Перед публикацией такого журнала удалите имена пользователей, внутренние адреса и другие сведения об инфраструктуре.

На Windows в PowerShell проверьте только TCP-порт:

Test-NetConnection -ComputerName SERVER_IP -Port 22

Ожидаемое поле TcpTestSucceeded : True означает, что порт принимает соединение. False подтверждает сетевую проблему, но не говорит, выключена ли служба или мешает firewall. Проверка с мобильного интернета помогает отличить ограничение офисной сети от проблемы самого VPS.

Если не отвечает не только SSH, но и сайт, сначала проверьте состояние VPS и сетевого интерфейса в панели. Подробный порядок для маршрута и адресов есть в статье о диагностике сети VPS.

Войдите через консоль хостера

Когда SSH недоступен, нужен независимый путь управления: веб-консоль, VNC-консоль, serial console или rescue-режим. Название зависит от хостера. Консоль соединяется с виртуальной машиной не через её SSH-порт, поэтому остаётся доступной при ошибке sshd или firewall внутри системы.

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

Проверьте службу OpenSSH на Ubuntu

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

sudo systemctl status ssh --no-pager
sudo journalctl -u ssh.service -n 100 --no-pager

В Ubuntu служба сервера OpenSSH называется ssh. Статус active (running) означает, что процесс запущен. inactive, failed или сообщение о несуществующей службе объясняют, почему порт может не слушаться. Журнал обычно указывает на ошибку конфигурации, отсутствующий ключ хоста или другую конкретную причину.

Если пакет сервера действительно не установлен, а VPS должен принимать SSH, установите его из настроенных репозиториев:

sudo apt-get update
sudo apt-get install openssh-server
sudo systemctl enable --now ssh

Команды изменяют систему: устанавливают пакет и включают запуск службы вместе с текущим стартом. При ошибке APT не скачивайте случайный пакет из стороннего сайта. Исправьте DNS, репозитории или свободное место и повторите установку.

Узнайте, где SSH слушает соединения

Запущенная служба может слушать не тот порт или только локальный адрес. Проверьте сокеты:

sudo ss -lntp | grep sshd

Строка 0.0.0.0:22 означает порт 22 на всех IPv4-интерфейсах, [::]:22 — на IPv6 и, в зависимости от настроек системы, также на IPv4. 127.0.0.1:22 принимает соединения только внутри VPS и не подходит для прямого удалённого входа.

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

Фактические параметры OpenSSH можно посмотреть без чтения всех комментариев конфигурации:

sudo sshd -T | grep -E '^(port|listenaddress|passwordauthentication|pubkeyauthentication) '

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

Исправляйте конфигурацию без потери сеанса

Основной файл — /etc/ssh/sshd_config, дополнительные настройки Ubuntu могут находиться в /etc/ssh/sshd_config.d/. Более ранняя строка из подключённого файла способна влиять на итог, поэтому ориентируйтесь на sshd -T.

Перед изменением сохраните копию конкретного файла. После правки обязательно проверьте синтаксис:

sudo sshd -t

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

Когда проверка проходит, примените изменение:

sudo systemctl restart ssh
sudo systemctl is-active ssh
sudo ss -lntp | grep sshd

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

Полная настройка ключей и запрета лишних способов входа разобрана в статье о безопасном SSH на Ubuntu.

Сопоставьте порт с firewall

Если sshd слушает нужный внешний адрес, проверьте firewall. Для UFW сначала достаточно команды чтения:

sudo ufw status numbered

Найдите разрешение именно для фактического SSH-порта. Если порт сменили с 22 на 2222, сначала добавьте новое правило, проверьте вход и только после этого удаляйте старое. Пример разрешения для всех источников:

sudo ufw allow 2222/tcp
sudo ufw status numbered

Команда изменяет firewall и подходит не каждой политике. Предпочтительнее ограничить административный вход доверенной сетью, если её адрес стабилен. Удалять правило нужно по номеру из свежего вывода ufw status numbered, потому что номера меняются после каждого удаления.

Кроме UFW могут действовать nftables, правила облачного firewall в панели хостера и ограничения маршрутизатора. Проверяйте их по одному. Не отключайте firewall целиком: это откроет другие службы и не докажет, какое правило было неверным. Различия механизмов объяснены в руководстве по UFW и nftables.

Когда причина находится вне VPS

Служба запущена, правильный порт слушается, а локальный firewall разрешает доступ — тогда проверьте внешний уровень:

• firewall или security group в панели хостера;
• проброс порта на роутере, если сервер за NAT;
• блокировку исходящего SSH в корпоративной сети;
• совпадение публичного IP с адресом VPS;
• защитную блокировку вашего адреса после серии неудачных входов.

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

Контрольная проверка после исправления

Успех подтверждается не только исчезновением Connection refused. Выполните новый вход с обычного компьютера, проверьте имя пользователя и узла, затем убедитесь, что прежний ошибочный порт больше не открыт, если вы его меняли.

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

Источники

• Ubuntu Server: OpenSSH server
• Linux manual: connect и ошибка ECONNREFUSED
• Ubuntu Server: firewall