SSH Connection Refused: причины и 5 способов исправить ошибку

Что означает ошибка "SSH Connection refused"

Ошибка ssh: connect to host <IP> port 22: Connection refused — это сообщение от клиента SSH, которое означает, что сервер активно отклонил попытку TCP-соединения на порту 22 (или другом указанном порту). В отличие от Connection timed out (где пакеты просто теряются), refused — это прямой ответ от ядра операционной системы сервера: "служба на этом порту не доступна".

Симптомы:

• Команда ssh user@server_ip завершается с ошибкой Connection refused практически мгновенно.
• Утилита telnet server_ip 22 также показывает Connection refused.
• Пинг (ping) до сервера, как правило, проходит успешно, так как проблема на транспортном (TCP) уровне, а не сетевом (ICMP).

Причины возникновения

Ошибка возникает на стороне сервера. Основные причины:

1. Служба SSH (sshd) не запущена. Это самая частая причина. Демон просто не слушает никакие порты.
2. SSH-демон слушает только локальный интерфейс (127.0.0.1). В конфигурации может быть указан ListenAddress 127.0.0.1, что разрешает подключения только с самого сервера.
3. Фаервол (брандмауэр) блокирует порт. Правило фаервола может быть настроено на REJECT (активный отказ) для порта 22 с вашего IP или для всех.
4. Другой процесс уже использует порт 22. Реже, но возможно, что другой сервис (например, старый sshd или другой демон) занял порт 22, и новый sshd не может его занять.
5. Конфигурационные ограничения в sshd_config. Директивы AllowUsers, DenyUsers, AllowGroups, DenyGroups или Match-блоки могут запрещать подключение для вашего пользователя или IP-адреса, что может приводить к отказу после установки соединения, но иногда и на этапе handshake.
6. Проблемы с SELinux/AppArmor. Системы mandatory access control могут запрещать sshd слушать сетевой порт или принимать соединения.
7. Сервер за NAT/ балансировщиком, а проброс портов не настроен. Клиент пытается подключиться к публичному IP, но пакеты не доходят до внутреннего сервера, а маршрутизатор сам отвечает RST (reset) или ICMP port unreachable.

Способ 1: Проверка и запуск службы SSH

Первым делом убедитесь, что служба работает.

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

   sudo systemctl status sshd
   

   • Если статус active (running) — служба работает, переходите к следующему способу.
   • Если статус inactive (dead) или failed — служба не запущена.
2. Запустите службу:

   sudo systemctl start sshd
   

3. Включите автозагрузку (чтобы служба запускалась после перезагрузки):

   sudo systemctl enable sshd
   

4. Попробуйте подключиться снова. Если ошибка осталась, проверьте, на каком порту служит служба (Способ 2).

Способ 2: Проверка, на каком порту и интерфейсе служит SSH

Узнайте, какие порты и сетевые интерфейсы слушает sshd.

1. Используйте ss или netstat:

   sudo ss -tlnp | grep sshd
   # или
   sudo netstat -tlnp | grep sshd
   

   
   Пример вывода для корректной настройки:

   tcp   LISTEN  0  128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=1234,fd=3))
   tcp   LISTEN  0  128  [::]:22  [::]:*  users:(("sshd",pid=1234,fd=4))
   

   • 0.0.0.0:22 — слушает на всех IPv4-интерфейсах.
   • [::]:22 — слушает на всех IPv6-интерфейсах.
   • 127.0.0.1:22 — слушает только локальный интерфейс (loopback). В этом случае внешние подключения невозможны.
2. Если слушает только 127.0.0.1, исправьте конфигурацию:
   • Откройте файл конфигурации SSH-сервера:

   sudo nano /etc/ssh/sshd_config
   

   • Найдите строку #ListenAddress 0.0.0.0 (или ListenAddress ::). Раскомментируйте её (удалите #) или добавьте, если её нет. Убедитесь, что нет строк ListenAddress 127.0.0.1.
   • Сохраните файл и перезапустите службу:

   sudo systemctl restart sshd
   

   • Проверьте вывод ss снова — теперь должны быть 0.0.0.0:22 и/или [::]:22.

Способ 3: Проверка и настройка фаервола

Фаервол может блокировать входящие соединения на порт 22.

Для ufw (Ubuntu/Debian по умолчанию)

sudo ufw status verbose

• Если статус Status: active, проверьте, есть ли правило для 22/tcp (или ssh). Если нет, добавьте:

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

• Если правило есть, но с ограничением по IP (22/tcp ALLOW IN 192.168.1.100), убедитесь, что ваш IP входит в список.
• Перезагрузите фаервол: sudo ufw reload.

Для firewalld (RHEL/CentOS/Rocky/Fedora)

sudo firewall-cmd --list-all

• В разделе services: или ports: должно быть ssh или 22/tcp.
• Если нет, добавьте правило на постоянной основе:

  sudo firewall-cmd --permanent --add-service=ssh
  # или
  sudo firewall-cmd --permanent --add-port=22/tcp
  

• Примените изменения: sudo firewall-cmd --reload.

Для iptables/nftables (базовый стек)

Просмотрите цепочку INPUT:

sudo iptables -L INPUT -n -v | grep 22

• Ищите правило с REJECT или DROP для порта 22. Если такое правило есть выше правила ACCEPT, оно блокирует трафик.
• Чтобы добавить правило разрешения в начало цепочки:

  sudo iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
  

• Сохраните правила (иначе они сбросятся после перезагрузки):
  • Для iptables: sudo iptables-save | sudo tee /etc/iptables/rules.v4
  • Для nftables: убедитесь, что конфиг в /etc/nftables.conf корректен и выполните sudo nft -f /etc/nftables.conf.

Способ 4: Проверка конфигурации SSH-сервера (sshd_config)

Неправильные настройки в /etc/ssh/sshd_config могут блокировать доступ.

1. Откройте файл конфигурации:

   sudo nano /etc/ssh/sshd_config
   

2. Проверьте ключевые директивы:
   • Port 22 — убедитесь, что порт указан корректно (если используете нестандартный, проверьте фаервол и подключение по -p).
   • ListenAddress — если эта директива присутствует, она должна быть 0.0.0.0 (для IPv4) или :: (для IPv6), а не 127.0.0.1.
   • PermitRootLogin — если вы пытаетесь подключиться под root, убедитесь, что значение yes или prohibit-password (если используете ключ).
   • PasswordAuthentication — если используете пароль, проверьте, что yes.
   • AllowUsers / AllowGroups — если эти директивы есть, убедитесь, что ваш пользователь (или группа) перечислен в них.
   • DenyUsers / DenyGroups — убедитесь, что ваш пользователь не указан здесь.
3. После внесения изменений перезапустите службу:

   sudo systemctl restart sshd
   

   • Важно: Не закрывайте текущую активную SSH-сессию (если она есть) до проверки новой конфигурации! Используйте sudo sshd -t для проверки синтаксиса файла перед перезапуском.

Способ 5: Проверка сетевых правил, SELinux/AppArmor и балансировщиков

Проверка SELinux (RHEL/CentOS/Rocky)

SELinux может запрещать sshd слушать порт.

sudo ausearch -m avc -ts recent | grep sshd

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

sudo semanage port -a -t ssh_port_t -p tcp 22

(Установите policycoreutils-python-utils, если semanage нет).

Проверка AppArmor (Ubuntu/Debian)

sudo aa-status | grep sshd

Если профиль sshd находится в режиме enforce, попробуйте перевести его в complain (для диагностики) или убедитесь, что профиль корректен:

sudo aa-complain /etc/apparmor.d/usr.sbin.sshd
sudo systemctl restart sshd

Проверка балансировщика/роутера

Если сервер находится за NAT (например, в облаке или дата-центре):

1. Убедитесь, что на роутере/в облачной панели (AWS Security Group, GCP Firewall, Yandex Cloud Security Group и т.д.) открыт порт 22 (или ваш кастомный порт) для вашего IP-адреса или диапазона.
2. Проверьте, что правило имеет приоритет выше правил "отклонить всё".
3. Если используете балансировщик нагрузки (ELB, HAProxy), убедитесь, что он настроен на проброс TCP-трафика на порт 22 к вашему бэкенду.

Профилактика

1. Всегда включайте автозагрузку критичных служб: sudo systemctl enable sshd.
2. Настраивайте фаервол сразу после развёртывания сервера и добавляйте правило для SSH до того, как включите его в продакшен.
3. Используйте нестандартный порт для SSH (например, 2222). Это не панацея от атак, но уменьшает количество автоматических сканирований. Не забудьте обновить фаервол и клиентскую команду (ssh -p 2222 user@host).
4. Регулярно проверяйте конфигурацию на наличие устаревших или конфликтующих директив (sshd_config, правила iptables/nftables).
5. Мониторьте логи SSH: sudo journalctl -u sshd -f в реальном времени или sudo cat /var/log/auth.log (Ubuntu/Debian) / sudo cat /var/log/secure (RHEL) для отслеживания попыток подключения и ошибок.

Дополнительная диагностика

Если ни один из способов не помог, соберите информацию для дальнейшего анализа:

1. Логи sshd:

   sudo journalctl -u sshd --since "5 min ago" | tail -50
   

   
   Ищите строки с Connection closed или refused.
2. Сетевой трафик (если есть доступ к серверу через консоль/KVM):

   sudo tcpdump -i any port 22 -nn
   

   
   Попробуйте подключиться с клиента. Если вы видите пакеты SYN от клиента, но нет пакетов SYN-ACK от сервера — проблема на стороне сервера (служба/фаервол). Если пакеты SYN не приходят — проблема на сети или балансировщике.
3. Проверка на наличие конфликтующего процесса:

   sudo lsof -i :22
   

   
   Убедитесь, что процесс — это sshd.
4. Проверка целостности пакетов:

   sudo apt update && sudo apt install --reinstall openssh-server  # Debian/Ubuntu
   sudo yum reinstall openssh-server                            # RHEL/CentOS
   

Внимание: После каждого значимого изменения конфигурации (фаервол, sshd_config) перезапускайте соответствующую службу (sudo systemctl restart sshd или sudo systemctl restart firewalld/ufw) и тестируйте подключение с клиента. Не закрывайте работающую консольную сессию до подтверждения работоспособности SSH.