SSH Connection Refused: диагностика и решение на Linux

Введение / Зачем это нужно

Ошибка SSH Connection refused — одна из самых частых при попытке удалённого подключения к Linux-серверу. Она означает, что на целевом хосте ни один процесс не слушает на TCP-порту 22 (или другом указанном вами). Это не проблема сети в целом (ping может работать), а конкретно недоступность SSH-сервиса.

В этом гайде вы узнаете, как системно диагностировать и устранить причину, восстановив безопасный удалённый доступ. Мы рассмотрим проверку службы, сетевых настроек, фаервола и конфигурации самого SSH.

Требования / Подготовка

Перед началом убедитесь, что:

• У вас есть доступ к целевому хосту локально (консоль, KVM, IPMI) или через альтернативный канал управления (например, веб-консоль облачного провайдера).
• Вы обладаете правами суперпользователя (sudo) на целевом хосте для проверки служб и изменения конфигурации.
• На клиентской машине установлен SSH-клиент (ssh).

Пошаговая инструкция

Шаг 1: Проверьте статус службы SSH

Первое, что нужно сделать — убедиться, что демон SSH (sshd) запущен.

# Для большинства современных дистрибутивов (RHEL, CentOS, Fedora, Ubuntu 22.04+)
sudo systemctl status sshd

# Для старых Debian/Ubuntu (имя службы может быть 'ssh')
sudo systemctl status ssh

Что искать в выводе:

• active (running) — служба работает.
• inactive (dead) или failed — служба остановлена или не запускается.

Если служба не запущена:

sudo systemctl start sshd    # Запустить сейчас
sudo systemctl enable sshd   # Включить автозагрузку

Шаг 2: Проверьте, слушает ли система порт 22

Даже если служба запущена, она может слушать только локальный интерфейс (127.0.0.1), что заблокирует внешние подключения.

sudo ss -tlnp | grep -E ':22|:ssh'

Или

sudo netstat -tlnp | grep ':22'

Критически важный вывод: В колонке Local Address:Port вы должны видеть 0.0.0.0:22 (для IPv4) или [::]:22 (для IPv6). Если указано 127.0.0.1:22 — SSH слушает только локальные подключения.

Шаг 3: Проверьте настройки фаервола

На современных Linux используется firewalld (RHEL/Fedora/CentOS) или ufw (Ubuntu/Debian). Неправильные правила — частая причина Connection refused.

Для firewalld:

sudo firewall-cmd --list-all

Убедитесь, что в разделе services: есть ssh или в ports: есть 22/tcp.

Чтобы добавить правило (если его нет):

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

Для ufw:

sudo ufw status verbose

Ищите 22/tcp (ssh) в списке Allow.

Чтобы разрешить:

sudo ufw allow ssh
# или явно по порту
sudo ufw allow 22/tcp

Шаг 4: Проверьте конфигурационный файл SSH

Откройте основной конфиг демона: /etc/ssh/sshd_config.

sudo nano /etc/ssh/sshd_config

На что обратить внимание:

1. Port 22 — убедитесь, что порт не закомментирован и равен 22 (или тому порту, который вы используете).
2. ListenAddress — если эта директива присутствует и указан 127.0.0.1 или ::1, SSH будет слушать только локальные подключения. Закомментируйте эту строку или укажите 0.0.0.0 (для всех IPv4-интерфейсов).
3. PermitRootLogin, PasswordAuthentication — эти параметры влияют на аутентификацию, но не на сам факт прослушивания порта. Однако их стоит проверить позже, если подключение будет устанавливаться, но не проходить аутентификацию.

После внесения изменений:

sudo sshd -t    # Проверить синтаксис конфига (без перезагрузки службы)

Если вывод пустой — синтаксис корректен.

Шаг 5: Перезапустите службу SSH

Примените все изменения, перезагрузив демон.

sudo systemctl restart sshd
# Проверьте статус снова, чтобы убедиться в успешном перезапуске
sudo systemctl status sshd

Проверка результата

С клиентской машины попробуйте подключиться снова:

ssh username@server_ip_address

Если подключение устанавливается, проблема решена. Если вы меняли стандартный порт, укажите его флагом -p:

ssh -p 2222 username@server_ip_address

Дополнительная проверка с помощью telnet или nc:

telnet server_ip_address 22
# или
nc -zv server_ip_address 22

Успешное подключение покажет, что порт открыт и служит SSH-демон.

Возможные проблемы

• SELinux/AppArmor блокирует SSH. На SELinux-системах (RHEL/CentOS/Fedora) проверьте логи: sudo ausearch -m avc -ts recent. Временное отключение для теста: sudo setenforce 0. Если проблема исчезнет, нужно настроить политику SELinux, а не оставлять её отключённой.
• Двойной NAT или облачный Security Group. Если сервер находится в облаке (AWS, GCP, Azure), убедитесь, что Security Group / Firewall Rules в панели управления облака разрешают входящий трафик на порт 22 с вашего IP-адреса. Это частая причина, когда на самой виртуальной машине всё настроено верно.
• SSH-демон слушает только IPv6, а клиент пытается по IPv4. Проверьте вывод ss -tlnp. Если видите только [::]:22, а не 0.0.0.0:22, добавьте в sshd_config ListenAddress 0.0.0.0.
• Конфликт портов. Убедитесь, что никакой другой процесс не использует порт 22: sudo lsof -i :22.
• Ошибки в конфиге после правки. Если sshd падает после перезапуска, смотрите логи: sudo journalctl -u sshd -n 50 --no-pager. Частые ошибки: неправильные права на файлы ключей (/etc/ssh/ssh_host_*), некорректные директивы.