Устранение ошибки SSH «connection refused»

SSH — это сетевой протокол для безопасного удалённого доступа и управления системами. Ошибка «connection refused» означает, что на TCP-порте, куда вы подключаетесь, либо ничего не слушает, либо активен краткий отказ (RST). Ниже — детальная проверка причин, команды, подсказки и готовый план действий.

Основные причины и быстрый чеклист

• SSH-сервер не установлен на удалённой машине.
• Служба SSH отключена или не запущена.
• SSH слушает нестандартный порт.
• Локальный или удалённый брандмауэр блокирует порт.
• Сетевой конфликт IP или неправильный маршрут.
• SELinux или политика безопасности запрещает соединения.

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

Если на целевой машине не установлен OpenSSH Server, подключение будет отвергнуто. Проверьте установку пакетного набора для вашей дистрибуции:

На 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 Server:

# Debian/Ubuntu
sudo apt install openssh-server

# RHEL/CentOS
sudo yum install openssh-server

# openSUSE
sudo zypper install openssh

# Arch
sudo pacman -S openssh

Совет: если вы устанавливаете сервер впервые, проверьте конфигурацию /etc/ssh/sshd_config на предмет параметра Port и PermitRootLogin.

2. Проверка статуса службы SSH

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

sudo systemctl status sshd

Если статус «inactive» или «failed», перезапустите и посмотрите логи:

sudo systemctl start sshd
sudo systemctl enable sshd
sudo journalctl -u sshd --no-pager | tail -n 50

Если служба падает сразу после старта, изучите журнал — часто причина в синтаксической ошибке в /etc/ssh/sshd_config.

3. Проверка порта SSH

По умолчанию SSH использует порт 22, но администраторы часто меняют его. Найдите порт, на котором слушает sshd:

sudo netstat -plntu | grep ssh

Или с modern-инструментами:

sudo ss -plntu | grep ssh

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

grep -i ^port /etc/ssh/sshd_config || sed -n '1,120p' /etc/ssh/sshd_config | grep -i port

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

ssh -p 5555 user@host

Совет: если вы используете NAT или проброс портов на роутере, убедитесь, что внешний порт проброшен на внутренний хост.

4. Проверка брандмауэра и политик безопасности

Частая причина — закрытый порт. Проверьте локальные и удалённые брандмауэры. Варианты:

UFW (Debian/Ubuntu/Arch):

sudo ufw status
sudo ufw allow ssh         # по имени (порт 22)
sudo ufw allow 5555/tcp    # по порту

firewalld (RHEL/openSUSE):

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

iptables / nftables:

# iptables пример
sudo iptables -L -n | grep 22

# nftables пример
sudo nft list ruleset | sed -n '1,200p'

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

Важно: отключать брандмауэр надолго нельзя в продакшне. Отключение только для диагностики; после — вернуть правила и открыть только нужные порты.

SELinux: в системах с SELinux убедитесь, что политика позволяет sshd работать на нестандартном порту:

sudo semanage port -l | grep ssh
# если порт нестандартный
sudo semanage port -a -t ssh_port_t -p tcp 5555

5. Проверка сетевых конфликтов и маршрутизации

IP-конфликт или неверный маршрут могут приводить к «connection refused», когда пакеты доходят не до того хоста. Для поиска конфликтов используйте arp-scan или простые утилиты:

# пример с arp-scan
sudo arp-scan 192.168.1.0/24

Также проверьте маршрут и доступность порта с вашей машины:

ping -c 3 host
nc -vz host 22     # netcat проверяет доступность TCP-порта
nmap -p 22,5555 host

Если ping падает, проверьте маршруты и настройки VLAN на коммутаторах.

Бонус: запуск SSH в режиме подробного логирования

Запустите ssh-клиент с ключом -vvv для подробных сообщений, это часто показывает точку отказа (например, «connection refused» сразу после TCP-соединения или зависание при аутентификации):

ssh -vvv user@host

Вывод -vvv покажет: DNS-резолвинг, попытки подключения, ответ RST или отсутствие ответа, этапы аутентификации.

Готовый пошаговый план действий (SOP) для администратора

1. Проверка доступности хоста: ping, traceroute.
2. Проверка открытых портов: nc, nmap.
3. Проверка установки sshd: пакетный менеджер.
4. Проверка статуса службы: systemctl status, journalctl.
5. Проверка слушающего порта: ss/netstat и /etc/ssh/sshd_config.
6. Проверка firewall: ufw/firewalld/iptables/nftables.
7. Проверка SELinux и правил безопасности.
8. Проверка конфликтов IP: arp-scan.
9. Диагностика клиента: ssh -vvv, локальный tcpdump, пример: sudo tcpdump -n -i any host x.x.x.x and port 22.
10. Применить фикс, проверить и зафиксировать изменения в CMDB.

Контроль приёмки

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

• Клиент может подключиться: ssh user@host успешно открывает shell.
• Время ответа приемлемо (пинг и время аутентификации в норме).
• Изменения задокументированы и внедрены в правила firewall/SELinux.

Быстрые альтернативные проверки и когда предложенные шаги не помогут

• Если sshd настроен правильно, но соединение всё равно отвергается, возможно, проблема на сетевом уровне (маршрутизация, ACL на роутере). Проверяйте лог маршрутизаторов и провайдера.
• При использовании облачных инфраструктур (AWS/GCP/Azure) проверьте security groups / network ACL / NSG и правила балансировщиков.
• Если ошибка проявляется только у одного пользователя — проверьте ограничения по IP/белые списки и sshd_config Match blocks.

Модель мышления и эвристики

Ментальная модель: «Пакет должен пройти три слоя» — доступность хоста (L3), открытый порт (L4), политика и аутентификация (L7). При сбое работайте сверху вниз: L3 → L4 → L7.

Роль‑ориентированные чеклисты

Для системного администратора:

• Проверить установку и версию openssh-server.
• Посмотреть логи sshd и системные логи.
• Проверить firewall и SELinux.
• Настроить мониторинг статуса sshd.

Для специалиста поддержки (helpdesk):

• Подтвердить IP/hostname и порт у пользователя.
• Спросить, изменял ли пользователь сетевые настройки.
• Попробовать подключиться с другой сети или устройства.

Для разработчика приложения:

• Проверить, не использует ли приложение нестандартный туннель.
• Убедиться, что аккаунт в ssh имеет правильные права и ключи.

Решение типичных ошибок и примерные команды восстановления

• sshd не установлен → установить пакет (apt/yum/zypper/pacman).
• sshd установлен, но не запущен → sudo systemctl start/enable sshd.
• порт закрыт → открыть в ufw/firewalld/iptables/nftables.
• SELinux блокирует нестандартный порт → semanage port.

Риск‑матрица и смягчение (качественно)

Мини‑глоссарий (одно предложение)

SSH — протокол для защищённого доступа к командной строке удалённой системы. OpenSSH — свободная реализация набора клиентов и серверов SSH. sshd — демон SSH на стороне сервера. ufw/firewalld — фронтенды для управления правилами брандмауэра.

Диагностическое дерево (Mermaid)

graph TD
  A[Проблема: connection refused] --> B{Хост доступен?}
  B -- Нет --> C[Проверить сеть: ping, traceroute, маршруты]
  B -- Да --> D{sshd установлен?}
  D -- Нет --> E[Установить openssh-server]
  D -- Да --> F{sshd запущен?}
  F -- Нет --> G[Запустить и проверить логи]
  F -- Да --> H{Порт правильный?}
  H -- Нет --> I[Узнать порт в sshd_config и подключиться с -p]
  H -- Да --> J{Firewall/SELinux блокирует?}
  J -- Да --> K[Открыть порт/настроить SELinux]
  J -- Нет --> L[Проверить IP/маршрутизацию/балансировщики]

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

Ошибку «connection refused» устраняют последовательной проверкой: доступность хоста, наличие и состояние sshd, порт и правила брандмауэра, сетевые конфликты и политики безопасности. Для диагностики используйте утилиты ping, nc/nmap, ss/netstat, journalctl и ssh -vvv. Документируйте изменения и возвращайте минимальный набор разрешений для безопасности.

Важно: перед внесением изменений в брандмауэр или SELinux планируйте откат и убедитесь, что у вас есть альтернативный доступ (например, консоль провайдера).