SSH Connection Refused на macOS: причины и быстрые решения

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

Ошибка SSH Connection Refused возникает, когда клиент SSH пытается установить соединение с сервером, но сервер (или промежуточное сетевое устройство) активно отклоняет подключение на указанном порту (по умолчанию 22). Полный текст ошибки обычно выглядит так:

ssh: connect to host example.com port 22: Connection refused

Это означает, что пакет SYN, отправленный на порт 22, получил ответ RST (reset) или не получил ответа, и соединение не может быть установлено. Ошибка возникает на этапе установки TCP-соединения, до начала SSH-рукопожатия. На macOS это часто встречается при попытке подключиться к удаленному серверу, локальному виртуальному машине или даже к собственному компьютеру, если SSH-сервер не настроен.

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

Ошибка Connection Refused может быть вызвана несколькими конкретными причинами:

1. SSH-сервер не запущен на целевом хосте — служба sshd не активна, поэтому порт 22 закрыт и не отвечает на запросы.
2. Брандмауэр блокирует порт 22 — на сервере или на клиенте (в случае исходящих подключений) брандмауэр отбрасывает пакеты на порт 22.
3. SSH-сервер настроен на нестандартный порт — если сервер использует порт, отличный от 22 (например, 2222), а клиент пытается подключиться к 22, соединение будет отклонено.
4. Сетевые проблемы — хост недоступен, маршрутизация не настроена, или есть проблемы с сетевым интерфейсом (например, Wi-Fi отключен).
5. Ограничения доступа в конфигурации SSH — файлы hosts.allow/hosts.deny или настройки sshd_config (например, AllowUsers или DenyUsers) могут запрещать подключение с вашего IP-адреса или пользователя.
6. Порт 22 занят другим процессом — на сервере другой сервис (например, веб-сервер) слушает порт 22, что вызывает конфликт.
7. IP-адрес сервера изменился или недоступен — если вы используете домен, DNS-запись может устареть, или сервер временно выключен.
8. На сервере исчерпан лимит соединений — если достигнут максимальное количество одновременных SSH-соединений, новые подключения будут отклонены.

Способы решения

Способ 1: Проверка и запуск SSH-сервера на целевом хосте

Если у вас есть доступ к целевому серверу (например, через консоль, KVM или панель управления хостингом), убедитесь, что служба SSH запущена. Для macOS и Linux-серверов:

На сервере (Linux с systemd):

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

   sudo systemctl status sshd
   

   Если служба неактивна (inactive), запустите её:

   sudo systemctl start sshd
   sudo systemctl enable sshd   # Для автозапуска при загрузке
   

На сервере (macOS):

1. Проверьте статус удаленного входа (SSH):

   sudo systemsetup -getremotelogin
   

   
   Если вывод Off, включите SSH:

   sudo systemsetup -setremotelogin on
   

   
   Или используйте launchctl:

   sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
   

2. Убедитесь, что порт 22 слушается:

   sudo lsof -i :22
   

   
   Вывод должен содержать процесс sshd (например, sshd 1234 root 3u IPv4 0x... TCP *:ssh (LISTEN)).
3. Если служба не запускается, проверьте логи на ошибки:

   sudo tail -f /var/log/system.log   # macOS
   sudo journalctl -u sshd -f         # Linux systemd
   

   
   Распространенные ошибки: неверные права на файлы конфигурации, конфликт портов.

Если сервер — это ваш собственный Mac: выполните те же шаги на вашем компьютере, чтобы убедиться, что локальный SSH-сервер активен (например, для тестирования подключения к localhost).

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

Брандмауэр может блокировать входящие или исходящие подключения на порт 22. Проверьте настройки на сервере и, если нужно, на клиенте.

На сервере (macOS):

1. Откройте Системные настройки → Брандмауэр → Параметры брандмауэра.
2. Убедитесь, что в списке разрешенных приложений есть sshd или Remote Login (SSH). Если нет, добавьте вручную:

   sudo /usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/sbin/sshd
   sudo /usr/libexec/ApplicationFirewall/socketfilterfw --unblockapp /usr/sbin/sshd
   

3. Также проверьте, включен ли брандмауэр:

   sudo /usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
   

   Если 1 — включен, 0 — выключен.

На сервере (Linux):

sudo iptables -L -n | grep 22

Или для nftables:

sudo nft list ruleset | grep 22

Разрешите порт, если нужно (пример для iptables):

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables-save | sudo tee /etc/iptables/rules.v4

На клиенте (ваш Mac): редко, но брандмауэр может блокировать исходящие подключения. Проверьте настройки в Системных настройках → Брандмауэр. По умолчанию исходящие разрешены, но если включены строгие правила, убедитесь, что приложению Terminal (или вашему SSH-клиенту) разрешены исходящие соединения.

Способ 3: Проверка сетевого подключения и правильности хоста

Убедитесь, что хост доступен и порт открыт, прежде чем винить в SSH.

1. Пропингуйте хост:

   ping example.com
   

   
   Если пинг не проходит (100% потерь), проблема с сетью или хост недоступен. Проверьте, подключены ли вы к интернету, и правильность DNS.
2. Проверьте доступность порта 22: Используйте nc (netcat) или telnet для теста подключения:

   nc -zv example.com 22
   

   
   Или:

   telnet example.com 22
   

   
   Возможные результаты:
   • Connection refused — порт закрыт или фильтруется.
   • Connection timed out — пакеты теряются (возможно, брандмауэр отбрасывает без ответа).
   • Connected to example.com — порт открыт, проблема может быть в SSH-конфигурации.
3. Убедитесь в правильности хоста и порта: проверьте, что вы используете правильное имя хоста или IP-адрес. Если SSH-сервер использует нестандартный порт (например, 2222), укажите его флагом -p:

   ssh -p 2222 user@example.com
   

4. Проверьте маршрутизацию: если сервер в локальной сети, убедитесь, что вы в той же подсети, и нет конфликтов IP.

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

Если у вас есть доступ к серверу (например, через консоль управления), проверьте конфигурационный файл sshd_config на предмет ошибок или ограничений.

1. Откройте файл:

   sudo nano /etc/ssh/sshd_config
   

   
   Или используйте vi/vim.
2. Убедитесь, что ключевые параметры настроены корректно:
   • Port 22 (или другой порт, который вы используете). Если порт изменен, клиент должен подключаться к нему.
   • ListenAddress 0.0.0.0 (для IPv4) или ListenAddress :: (для IPv6) — чтобы слушать все интерфейсы. Если указан конкретный IP, подключения с других адресов будут отклонены.
   • PermitRootLogin — если вы пытаетесь подключиться как root, убедитесь, что разрешено (yes или prohibit-password).
   • AllowUsers или DenyUsers — проверьте, что ваш пользователь не запрещен.
   • PasswordAuthentication — если вы используете пароль, должно быть yes (или no для ключей).
   • MaxAuthTries — если исчерпаны попытки аутентификации, новые подключения могут отклоняться.
3. После изменений перезапустите SSH-сервер:

   sudo systemctl restart sshd   # Linux
   sudo launchctl stop com.openssh.sshd && sudo launchctl start com.openssh.sshd   # macOS
   

4. Проверьте логи на наличие ошибок при перезапуске:

   sudo tail -f /var/log/auth.log   # Linux (Debian/Ubuntu)
   sudo tail -f /var/log/secure     # Linux (RHEL/CentOS)
   sudo tail -f /var/log/system.log   # macOS
   

   
   Ищите строки с sshd и error или failed.

Способ 5: Проверка файлов hosts.allow и hosts.deny

На некоторых системах используются TCP- wrappers (с файлами hosts.allow и hosts.deny) для ограничения доступа к службам.

1. Проверьте содержимое файлов:

   cat /etc/hosts.allow
   cat /etc/hosts.deny
   

   
   Обычно, чтобы разрешить всем, в hosts.allow должна быть строка:

   sshd: ALL
   

   
   Если в hosts.deny есть строка ALL: ALL, она может перекрывать разрешения. Порядок обработки: сначала hosts.allow, затем hosts.deny.
2. Если есть ограничения, добавьте ваш IP-адрес или сеть в hosts.allow:

   sshd: 192.168.1.0/24
   sshd: 203.0.113.5
   

3. После изменений перезапустите SSH-сервер (см. Способ 4).

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

Чтобы избежать повторения ошибки SSH Connection Refused, следуйте этим рекомендациям:

• Регулярно обновляйте систему и OpenSSH — это обеспечивает безопасность и исправление известных уязвимостей. На macOS используйте Системные настройки → Обновление ПО.
• Настраивайте брандмауэр правильно — разрешайте только необходимые порты и IP-адреса для SSH. Используйте инструменты вроде fail2ban (на Linux) для защиты от брутфорса, но на macOS убедитесь, что встроенный брандмауэр не блокирует легитимные подключения.
• Мониторьте логи SSH — регулярно проверяйте /var/log/auth.log (Linux) или system.log (macOS) на подозрительную активность или ошибки. Можно настроить оповещения.
• Используйте SSH-ключи вместо паролей — это безопаснее и удобнее. Сгенерируйте ключ с ssh-keygen -t ed25519 и добавьте публичный ключ в ~/.ssh/authorized_keys на сервере. Отключите аутентификацию по паролю (PasswordAuthentication no в sshd_config), если возможно.
• Изменяйте стандартный порт 22 — для уменьшения числа автоматических атак. Но убедитесь, что новый порт открыт в брандмауэре, и документируйте изменение. Подключайтесь с флагом -p.
• Регулярно проверяйте доступность сервера — используйте простые скрипты мониторинга (например, nc -z в cron) или сервисы вроде UptimeRobot, чтобы быстро обнаруживать падение SSH-сервиса.
• Документируйте изменения конфигурации — если вы меняете настройки SSH (порт, доступ пользователей), записывайте их в отдельный файл или систему контроля версий, чтобы легко откатить при проблемах.
• Тестируйте изменения в изолированной среде — перед применением конфигурации на продакшн-сервере проверьте её на тестовом хосте.
• Ограничивайте доступ по IP — если сервер используется только из определенных сетей, настройте брандмауэр или sshd_config (через Match блоки) для разрешения только доверенных IP-адресов.