SSH: ошибка 'Disconnected by remote host' — причины и решения

Что означает ошибка "Disconnected by remote host"

Ошибка Connection closed by remote host (или Received disconnect from <IP> port 22:11: Bye Bye) — это сообщение от SSH-сервера, который сознательно разорвал установленное соединение. Клиент (ваша локальная машина) получает этот сигнал и завершает сессию. Это не всегда сбой; иногда это штатное действие (например, завершение работы sshd), но чаще — признак проблемы с конфигурацией, сетью или ресурсами сервера.

Сообщение обычно появляется в клиентской консоли сразу после ввода пароля или через некоторое время бездействия.

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

1. Таймаут неактивности (Idle Timeout): Сервер разрывает соединение после периода бездействия (по умолчанию в некоторых дистрибутивах может быть 5-10 минут). Клиент не отправляет данные, сервер считает сессию мёртвой.
2. Несоответствие настроек keepalive: Клиент и/или сервер не настроены на отправку периодических "живых" пакетов (keepalive), что позволяет обнаружить разрыв или поддерживать активность.
3. Проблемы с аутентификацией: Неверные права на файлы ~/.ssh/authorized_keys (должны быть 600) или ~/.ssh (700) на сервере. Сервер отвергает ключ и закрывает соединение.
4. Перегрузка сервера или исчерпание ресурсов: Сервер исчерпал лимиты процессов (MaxStartups), сессий или памяти (ulimit), и sshd принудительно закрывает новые или существующие соединения.
5. Сетевая проблема или срабатывание firewall: Промежуточное сетевое устройство (роутер, корпоративный фаервол) разрывает "молчаливое" TCP-соединение по истечении таймаута. Также возможен блокирующий DROP пакетов SSH.
6. Конфликт портов или служб: На сервере уже запущен другой демон на порту 22 (или кастомном порте SSH), или sshd перезапускается (например, после обновления конфига).
7. Проблема с GSSAPI-аутентификацией: Включённый по умолчанию в некоторых версиях OpenSSH механизм GSSAPI может вызывать задержки и таймауты, приводящие к разрыву.

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

Способ 1: Настройка keepalive на стороне клиента (самый частый и простой)

Это заставит ваш SSH-клиент периодически отправлять пустые пакеты, чтобы "оживлять" соединение.

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

   nano ~/.ssh/config
   

2. Добавьте блок конфигурации для нужного хоста (или используйте Host * для всех):

   Host *
       ServerAliveInterval 60
       ServerAliveCountMax 3
   

   • ServerAliveInterval 60 — отправлять пакет каждые 60 секунд.
   • ServerAliveCountMax 3 — если 3 пакета подряд не получили ответ, разорвать соединение (итоговый таймаут ~3 минуты).
3. Сохраните файл (Ctrl+O, Enter, Ctrl+X). Переподключитесь. Эта настройка действует только для исходящих соединений с вашей машины.

💡 Совет: Если вы подключаетесь к разным серверам с разными политиками, настройте Host-блоки для каждого.

Способ 2: Настройка keepalive на стороне сервера

Если вы имеете административный доступ к серверу, измените его конфигурацию sshd.

1. Подключитесь к серверу (возможно, через консоль управления, если SSH падает).
2. Отредактируйте главный конфиг sshd:

   sudo nano /etc/ssh/sshd_config
   

3. Найдите (или добавьте) параметры и установите значения:

   ClientAliveInterval 60
   ClientAliveCountMax 3
   

   • ClientAliveInterval — сервер будет отправлять пакеты клиенту каждые N секунд.
   • ClientAliveCountMax — количество "живых" запросов без ответа, после которых сервер разрывает соединение.
4. Перезапустите службу SSH:

   sudo systemctl restart sshd
   

   ⚠️ Важно: Не закрывайте текущую сессию до проверки новой! Рекомендуется открыть вторую консоль для теста.

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

Неправильные права на ~/.ssh и authorized_keys — частая причина немедленного разрыва после попытки аутентификации.

На сервере (для пользователя, под которым вы подключаетесь):

# Перейдите в домашнюю директорию целевого пользователя
cd ~

# Установите корректные права
chmod 700 .ssh
chmod 600 .ssh/authorized_keys

# Проверьте владельца (должен быть сам пользователь, не root!)
ls -la .ssh/

Если владелец неверный, исправьте:

sudo chown -R <username>:<username> .ssh

Способ 4: Диагностика сети и firewall

1. Проверьте стабильность соединения с сервера на клиенте:

   ping -c 20 <server_ip>
   

   Ищите потерю пакетов (packet loss). Даже 1-2% могут вызывать проблемы.
2. Проверьте путь (traceroute) для выявления узлов с задержками:

   traceroute <server_ip>
   

3. Проверьте firewall на сервере (если есть доступ):

   # Для firewalld (CentOS/RHEL/Fedora)
   sudo firewall-cmd --list-all
   
   # Для ufw (Ubuntu/Debian)
   sudo ufw status verbose
   
   # Для iptables (универсально)
   sudo iptables -L -n -v
   

   Убедитесь, что порт SSH (по умолчанию 22 или указанный вами в sshd_config) разрешён для входящих соединений (ACCEPT).
4. Проверьте firewall на клиенте (особенно если вы в корпоративной сети). Возможно, исходящий трафик на порт 22 блокируется.

Способ 5: Увеличение лимитов на стороне сервера

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

1. На сервере в /etc/ssh/sshd_config найдите или добавьте:

   MaxStartups 100:30:200
   

   • Формат: начальное_значение:процент_сброса:максимум. Пример: разрешить 100 одновременных подключений, начиная сбрасывать 30% новых при достижении 150, верхний предел 200.
2. Также проверьте системные лимиты (ulimit -n для файловых дескрипторов). При необходимости увеличьте в /etc/security/limits.conf и перезагрузите сервер.
3. Перезапустите sshd:

   sudo systemctl restart sshd
   

Способ 6: Отключение GSSAPI (если проблема в нём)

GSSAPI-аутентификация (для интеграции с Kerberos) может вызывать задержки.

1. На клиенте в ~/.ssh/config добавьте для проблемного хоста:

   Host <server_alias_or_ip>
       GSSAPIAuthentication no
   

2. Или на сервере в /etc/ssh/sshd_config:

   GSSAPIAuthentication no
   

   Затем перезапустите sshd.

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

• Настройте keepalive на клиенте и сервере (Способ 1 и 2) для всех критических соединений, особенно через нестабильные сети.
• Регулярно обновляйте OpenSSH (sudo apt update && sudo apt upgrade openssh-server на Debian/Ubuntu, sudo yum update openssh на RHEL/CentOS) для получения исправлений безопасности и стабильности.
• Мониторьте логи SSH (sudo journalctl -u sshd -f) при возникновении проблем, чтобы сразу видеть причину.
• Следите за нагрузкой сервера (top, htop, free -h). Резкие всплески нагрузки могут приводить к таймаутам.
• Правильно настраивайте права (chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys) и владельца (chown) файлов аутентификации.