Освойте инструменты и лучшие практики DevOps — Центр знаний DevOps Освойте инструменты и лучшие практики DevOps — Центр знаний DevOps

Быстрое устранение ошибок отказа в SSH-подключении

Исправьте ошибки отказа в SSH-подключении, проверив статус sshd, порты, правила брандмауэра, sshd_config, SELinux и журналы сервера.

Быстрое устранение ошибок отказа в SSH-подключении

SSH (Secure Shell) является основой удаленного управления серверами, обеспечивая безопасную и зашифрованную связь между вашим локальным компьютером и удаленным сервером. Однако столкновение с ошибкой ssh: connect to host <IP_ADDRESS> port 22: Connection refused может стать серьезным препятствием, мешая вам получить доступ к вашим критически важным системам.

Эта статья представляет собой подробное пошаговое руководство по диагностике и устранению распространенной ошибки «Отказ в подключении». Мы рассмотрим основные причины, от неактивных демонов SSH до неправильно настроенных брандмауэров и неверных настроек сервера, предоставив вам знания и команды для быстрого восстановления доступа к вашим серверам.

Понимание ошибки «Отказ в подключении»

Когда вы получаете ошибку Connection refused, это означает, что ваш SSH-клиент успешно достиг удаленного сервера, но сервер явно отклонил подключение на указанном порту. Это отличается от ошибки Connection timed out (когда клиент вообще не смог достичь сервера) или ошибки No route to host (когда сетевой путь нарушен).

Статус «отказано» напрямую указывает на проблему на стороне сервера, которая активно препятствует принятию подключений службой SSH. Обычно это связано с тем, что демон SSH не запущен, брандмауэр блокирует подключение или неправильная конфигурация самой службы SSH.

Распространенные причины «Отказа в подключении»

Несколько факторов могут привести к отказу в SSH-подключении. Понимание их помогает сузить круг поиска при устранении неполадок:

  • Демон SSH (sshd) не запущен: Самая распространенная причина. Процесс SSH-сервера мог аварийно завершиться, быть остановлен или не запуститься при загрузке.
  • Брандмауэр блокирует порт 22 (или пользовательский порт): Брандмауэр сервера (например, UFW, firewalld, iptables) предотвращает входящие подключения на SSH-порт.
  • Неправильная конфигурация демона SSH: Файл sshd_config может быть настроен некорректно, из-за чего демон SSH прослушивает другой порт, неправильный сетевой интерфейс или отклоняет подключения для определенных пользователей/методов.
  • Проблемы с сетевым подключением (менее распространены для «Отказано»): Хотя это менее вероятно для ошибки «отказано», фундаментальная сетевая проблема иногда может проявиться неожиданно.
  • Ограничения SELinux или AppArmor: Усовершенствования безопасности, такие как SELinux или AppArmor, могут препятствовать правильной работе sshd, особенно после пользовательских конфигураций или изменений в системе.

Пошаговое руководство по устранению неполадок

Давайте перейдем к практическим шагам по диагностике и исправлению ошибки «Отказ в подключении».

Шаг 1: Проверка статуса демона SSH на сервере

Первое, что нужно проверить, — запущен ли демон SSH-сервера (sshd) на вашем удаленном компьютере. Обычно вам понадобится доступ к консоли (например, через консоль облачного провайдера или физическое подключение), чтобы выполнить эти проверки, если SSH полностью недоступен.

  1. Проверьте статус демона SSH: В большинстве современных дистрибутивов Linux (использующих systemd, таких как Ubuntu, CentOS 7+, Debian 8+):
    sudo systemctl status sshd

В Debian/Ubuntu служба может называться ssh:

sudo systemctl status ssh ``` Если sshd не запущен, вывод укажет inactive (dead) или аналогичный статус.

  1. Запустите демон SSH: Если статус неактивен, попробуйте запустить службу:
    sudo systemctl start sshd

Или в Debian/Ubuntu:

sudo systemctl start ssh ```

  1. Включите демон SSH для автоматического запуска при загрузке: Чтобы SSH запускался автоматически после перезагрузки, включите его:
    sudo systemctl enable sshd

Или в Debian/Ubuntu:

sudo systemctl enable ssh ```

  1. Проверьте журналы демона SSH: Если sshd не удается запустить, его журналы могут дать важные подсказки. Для систем с systemd:
    sudo journalctl -u sshd --since "10 minutes ago"

Или, если ваш дистрибутив использует модуль ssh:

sudo journalctl -u ssh --since "10 minutes ago" Кроме того, проверьте общие журналы аутентификации: bash sudo tail -f /var/log/auth.log # Или для RHEL/CentOS: sudo tail -f /var/log/secure ```

Шаг 2: Проверка правил брандмауэра

Брандмауэр на стороне сервера часто является причиной отказов в подключении. Он может блокировать стандартный порт SSH (22) или пользовательский порт, который вы пытаетесь использовать. Вам необходимо убедиться, что брандмауэр разрешает входящие подключения на SSH-порт.

  1. Определите ваш брандмауэр: Распространенные брандмауэры включают:

    • UFW (Uncomplicated Firewall): Распространен в Ubuntu/Debian.
    • firewalld: Распространен в CentOS/RHEL 7+.
    • iptables: Базовый брандмауэр для Linux, настраиваемый напрямую или через интерфейсы.

  2. Проверьте статус и правила брандмауэра:

    • UFW:
      sudo ufw status verbose
      Ищите правила, разрешающие трафик на port 22 (или ваш пользовательский SSH-порт). Если SSH указан, убедитесь, что он ALLOW (разрешен).
    • firewalld:
      sudo firewall-cmd --list-all
      Проверьте разделы services и ports на наличие ssh или port 22/tcp.
    • iptables:
      sudo iptables -L -v -n
      Этот вывод может быть сложным. Ищите правила DROP или REJECT, связанные с tcp dpt:22 (или вашим пользовательским портом) в цепочке INPUT.

  3. Разрешите SSH-порт через брандмауэр:

    • UFW:
      sudo ufw allow ssh        # Разрешает порт 22
# Или для пользовательского порта (например, 2222):
sudo ufw allow 2222/tcp
sudo ufw enable           # Если UFW неактивен
    • firewalld:
      sudo firewall-cmd --permanent --add-service=ssh
# Или для пользовательского порта (например, 2222):
sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
    • iptables: Добавление правил iptables напрямую более сложно и временно, если не сохранено. Обычно рекомендуется использовать firewalld или ufw, если они доступны. Для быстрой проверки (непостоянной):
      sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Вам нужно будет сохранить эти правила, если вы хотите, чтобы они сохранялись после перезагрузки.

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

Шаг 3: Проверка конфигурации SSH (sshd_config)

Файл конфигурации демона SSH (/etc/ssh/sshd_config) определяет, как работает служба. Неправильные настройки здесь могут привести к отказу в подключении.

  1. Найдите sshd_config: Основной файл конфигурации обычно находится по адресу /etc/ssh/sshd_config.

  2. Проверьте ключевые настройки: Откройте файл в текстовом редакторе (например, nano, vi):

    sudo nano /etc/ssh/sshd_config

    Обратите внимание на следующие директивы:

    • Port: Указывает порт, который прослушивает sshd. Убедитесь, что он соответствует порту, к которому вы пытаетесь подключиться с вашего клиента. Если он закомментирован (#), по умолчанию используется порт 22.
    • ListenAddress: Если присутствует, указывает, какие IP-адреса должен прослушивать sshd. Если он установлен на внутренний IP (например, 127.0.0.1), а вы подключаетесь из внешней сети, он отклонит подключение. Для прослушивания всех интерфейсов он часто закомментирован или установлен на 0.0.0.0 или :: (для IPv6).
    • PermitRootLogin: Если установлено значение no, вы не сможете войти в систему как root. Хотя это не является «отказом в подключении» в строгом смысле (часто это отказ в разрешении после подключения), это может помешать успешным попыткам входа.
    • PasswordAuthentication: Если установлено значение no, аутентификация по паролю отключена, требуется аутентификация по ключу.

    Совет: После внесения любых изменений в sshd_config вы должны перезапустить службу SSH, чтобы они вступили в силу:

    sudo systemctl restart sshd

Шаг 4: Сетевое подключение (базовая проверка)

Хотя «отказ в подключении» обычно означает, что сервер был достигнут, всегда полезно быстро подтвердить базовую сетевую доступность с вашего клиентского компьютера до IP-адреса сервера.

  1. Пинг сервера: С вашего клиентского компьютера попробуйте выполнить пинг IP-адреса или имени хоста сервера:

    ping <SERVER_IP_ADDRESS_OR_HOSTNAME>

    Если пинг не удается (100% потеря пакетов), у вас более фундаментальная сетевая проблема (например, неверный IP, сервер не в сети, проблема с сетевой маршрутизацией), которую необходимо решить до SSH.

  2. Используйте nc или telnet (с клиента): Чтобы проверить, открыт ли порт и прослушивается ли он с точки зрения клиента:

    # Использование netcat (nc)
nc -zv <SERVER_IP_ADDRESS> 22

# Использование telnet
telnet <SERVER_IP_ADDRESS> 22

    Если nc показывает Connection refused или telnet сразу завершает работу, это подтверждает, что сервер активно отклоняет подключение на этом порту, что указывает на демон SSH или брандмауэр.

Шаг 5: Проверка SELinux или AppArmor (продвинутый уровень)

В некоторых усиленных средах или после пользовательских конфигураций SELinux (Security-Enhanced Linux) или AppArmor могут препятствовать правильной работе sshd, особенно если вы используете нестандартный порт SSH.

  1. Проверьте статус SELinux:

    sestatus

    Если SELinux находится в режиме enforcing, возможно, вам потребуется настроить его политики, чтобы разрешить sshd на пользовательском порту. Например, чтобы разрешить порт 2222 для SSH:

    sudo semanage port -a -t ssh_port_t -p tcp 2222
sudo systemctl restart sshd

    (Установите semanage, если он недоступен: sudo apt install policycoreutils-python-utils в Debian/Ubuntu, sudo yum install policycoreutils-python-utils или соответствующий пакет для вашего релиза семейства RHEL).

  2. Проверьте статус AppArmor:

    sudo aa status

    Если AppArmor находится в режиме enforcing, проверьте его журналы (/var/log/syslog или dmesg) на предмет любых отказов, связанных с sshd.

Шаг 6: Повторная проверка журналов сервера

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

  • sudo journalctl -u sshd
  • sudo tail -f /var/log/auth.log (или /var/log/secure)

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

Лучшие практики для предотвращения будущих проблем

  • Регулярно обновляйте вашу ОС: Поддерживайте операционную систему и пакеты вашего сервера, включая openssh-server, в актуальном состоянии.
  • Тестируйте правила брандмауэра: После внедрения или изменения правил брандмауэра всегда немедленно тестируйте их.
  • Создавайте резервные копии sshd_config: Перед внесением изменений в /etc/ssh/sshd_config сделайте резервную копию (sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak).
  • Используйте консоль управления: Для облачных экземпляров знайте, как получить доступ к консоли сервера (например, последовательная консоль AWS EC2, консоль Google Cloud), чтобы устранять неполадки сети, когда SSH недоступен.
  • Мониторьте журналы: Регулярно просматривайте журналы auth.log или secure на предмет необычной активности или постоянных ошибок.

Заключение

Ошибка отказа в SSH-подключении обычно означает, что сервер доступен, но ничто не принимает ваше подключение на этом порту. Проверьте имя службы SSH для вашего дистрибутива, подтвердите, что порт прослушивается, откройте брандмауэр, проверьте sshd_config и прочитайте журналы, прежде чем вносить более серьезные изменения. Если у вас все еще есть один работающий сеанс, не закрывайте его, пока новый вход не будет успешным.