SSH: устранение ошибки «Connection refused»

SSH — это сетевой протокол для безопасного доступа и управления удалённой системой. Ошибка “connection refused” появляется, когда клиент пытается подключиться, но на стороне сервера нет процесса, слушающего соответствующий порт, или пакет блокируется. Ниже — практическое руководство по поиску и устранению причин.

Что проверять в первую очередь

• Установлен ли SSH-сервер на удалённой машине
• Запущен ли сервис sshd
• На каком порту слушает sshd (по умолчанию 22)
• Не блокирует ли соединение фаерволл/маршрутизатор
• Нет ли конфликта IP-адресов
• Какие сообщения выдаёт клиент в режиме отладки

1. Проверьте, установлен ли SSH‑сервер

Если на удалённой машине отсутствует SSH‑сервер, соединение будет отвергнуто. Установку и наличие пакета можно проверить пакетным менеджером дистрибутива.

На Debian/Ubuntu:

dpkg --list | grep ssh

На RHEL/CentOS:

yum list installed | grep ssh

На openSUSE:

zypper search -i | grep ssh

На Arch Linux:

pacman -Q | grep ssh

Если пакет не установлен, установите OpenSSH:

На Debian/Ubuntu:

sudo apt install openssh-server

На RHEL/CentOS:

sudo yum install openssh-server

На openSUSE:

sudo zypper install openssh

На Arch Linux:

sudo pacman -S openssh

Важно: пакеты называются по-разному в отдельных дистрибутивах; проверяйте имя именно для вашей версии ОС.

2. Проверьте статус сервиса SSH

После установки убедитесь, что служба запущена и активна.

sudo systemctl status sshd

Ожидаемый результат: активна (active (running)). Если статус inactive или failed — запустите и включите автозапуск:

sudo systemctl start sshd
sudo systemctl enable sshd

Если systemctl недоступен (старые системы), используйте init‑скрипты или systemv‑инструменты (service sshd start).

3. Проверьте порт SSH

По умолчанию SSH использует порт 22, но администратор мог изменить его в /etc/ssh/sshd_config. Уточните, на каком порту слушает демон.

Найти процессы и порты можно с помощью netstat или ss:

sudo netstat -plntu | grep ssh

Или с ss:

sudo ss -plntu | grep ssh

Посмотреть конфигурацию:

grep -i '^Port' /etc/ssh/sshd_config || echo "Port стандартный: 22"

Если порт отличается от 22, подключайтесь явно:

ssh -p 5555 user@host

Совет: иногда администраторы добавляют правило в файрвол/маршрутизатор только для нестандартного порта — учтите это при проверке.

4. Проверьте фаервол и правила безопасности

Частая причина — фаервол блокирует входящие соединения. Временное отключение фаервола помогает подтвердить гипотезу; после проверки обязательно включите его обратно.

Отключить UFW (Debian/Ubuntu/Arch):

sudo ufw disable

Отключить firewalld (RHEL/openSUSE):

sudo systemctl stop firewalld
sudo systemctl disable firewalld

Если после отключения фаервола подключение появилось — добавьте правило вместо продолжительного отключения.

Разрешить SSH в UFW:

sudo ufw allow ssh

Или по порту:

sudo ufw allow 5555/tcp

Для firewalld (постоянно):

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-port=4444/tcp
sudo firewall-cmd --reload

Проверить правила:

sudo ufw status
sudo firewall-cmd --list-all

Примечание: облачные провайдеры (AWS/GCP/Azure) имеют внешние правила безопасности (Security Groups, NSG). Проверьте их отдельно — они могут блокировать порт до вашего хоста.

5. Проверьте конфликты IP и сетевые проблемы

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

arp-scan 192.168.1.0/24

В выводе будут перечислены все MAC‑адреса и соответствия IP. При обнаружении дубликата — избавьтесь от статической настройки, пересмотрите DHCP‑пул или назначьте уникальные адреса.

Бонус: запускайте SSH в режиме отладки

Для детальной диагностики подключайтесь с опцией -vvv. Это выводит шаги установки соединения, хэндшейк и возможные ошибки.

ssh -vvv username@ip_address

Вы увидите, например, где именно происходят таймауты, отклонения или отказ в доступе.

Пошаговый план диагностики (минимальная методология)

1. Убедитесь, что адрес и имя хоста корректны.
2. Проверьте, установлен ли openssh-server.
3. Проверьте статус sshd и автозапуск.
4. Определите порт, на котором слушает sshd.
5. Отключите локальный фаервол для проверки, затем добавьте правило.
6. Проверьте внешние ACL/маршрутизаторы/облачные Security Groups.
7. Запустите ssh с -vvv и проанализируйте вывод.
8. Проверьте IP‑конфликты и сетевые проблемы.

Decision tree (схема принятия решения)

flowchart TD
  A[Попытка подключения: Connection refused] --> B{Пакет до хоста доходит?}
  B -- Нет --> C[Проверить маршрутизацию/маршрутизатор/ACL]
  B -- Да --> D{Сервер слушает порт?}
  D -- Нет --> E[Установить/запустить sshd]
  D -- Да --> F{Фаервол блокирует?}
  F -- Да --> G[Добавить правило/открыть порт]
  F -- Нет --> H{IP конфликт или SELinux?}
  H -- Да --> I[Исправить конфликт/проверить SELinux]
  H -- Нет --> J[Запустить ssh -vvv и читать лог]

Ролевые чек-листы

• Системный администратор:

  • Проверить установку openssh-server и статус sshd
  • Проверить /etc/ssh/sshd_config на предмет нестандартного порта
  • Проверить логи: /var/log/auth.log или journalctl -u sshd
  • Проверить правила фаервола и сетевые ACL

• Оператор/DevOps:

  • Проверить cloud security groups / firewall rules
  • Проверить NAT/порт‑форвардинг на гейтвее
  • Протестировать подключение изнутри и снаружи сети

• Служба поддержки/Helpdesk:

  • Уточнить IP и порт у пользователя
  • Попросить пользователя прислать вывод ssh -vvv
  • Проверить статус доступности порта с помощью telnet/nc

Критерии приёмки

• Клиент успешно устанавливает SSH‑соединение и получает приглашение на ввод пароля/ключа.
• ssh -vvv не показывает ошибок «connection refused» и доходит до этапа key exchange.
• Если требовалась смена правил фаервола — правило отображается в списке активных правил.

Тесты и кейсы при проверке

• Позитивный: установка соединения с локального хоста к локальному адресу, порт 22 — ожидаемый результат: подключение работает.
• Негативный: порт закрыт — ожидаемый результат: ssh клиента возвращает «Connection refused».
• Сценарий нестандартного порта: попытка без -p возвращает отказ; с -p — подключение успешно.
• Сценарий облачных правил: локальная машина доступна, а из интернета — отказ (проверить Security Group).

Рекомендации по повышению безопасности SSH

• Отключите вход по паролям, используйте только аутентификацию по ключам:

# в /etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no

• Отключите аккаунт root для прямого входа:

PermitRootLogin no

• Используйте Fail2Ban или аналог для защиты от подборов паролей.
• Ограничьте вход по IP (AllowUsers/AllowGroups или сетевые ACL) для административных учётных записей.
• По возможности оставьте SSH на нестандартном порту и сочетайте с ограничениями доступа.
• Включите двухфакторную аутентификацию (например, через PAM модуль) для критичных серверов.

Важно: изменения в /etc/ssh/sshd_config требуют перезапуска sshd: sudo systemctl restart sshd

SELinux и AppArmor

Если на системе включены SELinux или AppArmor, они могут блокировать сетевые сервисы. Проверьте audit‑логи и временно переключите режим в permissive для проверки.

SELinux временно в permissive:

sudo setenforce 0

После диагностики верните enforce и исправьте политику.

Короткая памятка команд

• Проверить процесс и порт: sudo ss -plntu | grep ssh
• Статус сервиса: sudo systemctl status sshd
• Перезапустить: sudo systemctl restart sshd
• Разрешить в UFW: sudo ufw allow ssh
• Проверить порт извне: nc -vz host port
• Отладка клиента: ssh -vvv user@host

Короткая галерея ошибок и когда предложенные шаги не помогут

• Проблемы аппаратного уровня (сетевой интерфейс, кабели, свитчи) — проверяйте физическую сеть
• Если проблема на стороне провайдера (маршрутизация/ISP) — обратитесь в поддержку провайдера
• Если NAT неправильно настроен на границе сети — подключение будет недоступно извне

Глоссарий (1‑строчная)

• SSH: защищённый протокол удалённого доступа; sshd — демон сервера; OpenSSH — популярная реализация.

Безопасность и защита персональных данных

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

Краткое резюме

• Ошибка “Connection refused” обычно указывает на отсутствие слушающего процесса или блокировку на сетевом уровне.
• Стандартная диагностика: проверить установку, статус sshd, порт, фаервол и вывод ssh -vvv.
• Примените рекомендации по безопасности (ключи вместо паролей, ограничение доступа) после восстановления подключения.

Авторитетная цитата: «Проверяйте сначала базовые вещи: установлен ли сервис и слушает ли он порт» — распространённая практика администраторов.

Социальный предпросмотр (OG) предложен в метаданных.