Ошибка «Remote side unexpectedly closed network connection» в MobaXterm означает, что SSH-сервер на удалённой стороне сам разорвал TCP-соединение — клиент тут лишь фиксирует факт обрыва. Поэтому диагностику нужно начинать не с переустановки программы, а с проверки состояния сервера: доступен ли он по сети, работает ли служба sshd и не отклоняет ли она именно вашу сессию.
Проблема проявляется по-разному: соединение рвётся сразу после ввода пароля, через несколько минут простоя или в момент установки канала. Каждый из этих сценариев указывает на свою группу причин — от неверных учётных данных и ограничений fail2ban до таймаутов NAT и нехватки ресурсов на сервере. Ниже разберём каждый вариант и порядок безопасной диагностики.
Что означает эта ошибка и когда она возникает
Сообщение появляется, когда удалённый хост корректно или аварийно закрывает сокет. Это принципиально отличается от ошибки Connection timed out, где сервер вообще не отвечает: здесь ответ был, но сессию завершили на той стороне.
Типичные сценарии:
- 🔌 Обрыв происходит мгновенно после подключения — вероятны ограничения на сервере:
AllowUsers/DenyUsersв конфигурации sshd, блокировка по hosts.deny или бан от fail2ban. - ⏱️ Сессия рвётся через несколько минут бездействия — срабатывает таймаут простоя на сервере, роутере или NAT-провайдера.
- 🔑 Разрыв сразу после аутентификации — проблемы с правами пользователя, переполненным диском на сервере или некорректным shell.
- 📉 Соединение падает под нагрузкой — нехватка памяти на сервере, ограничения
MaxSessionsили нестабильный канал связи.
Точную причину почти всегда видно в логах сервера, поэтому доступ к ним (например, через панель хостера, VNC-консоль или другой рабочий сеанс) сильно ускоряет диагностику.
Шаг 1. Проверка доступности сервера и службы SSH
Первым делом убедитесь, что сервер вообще жив и принимает подключения на нужном порту. Самый простой тест — попытаться подключиться к тому же хосту другим клиентом, например встроенным OpenSSH в Windows:
ssh -v пользователь@адрес_сервера -p 22Флаг -v выводит подробный лог рукопожатия. Если и здесь соединение обрывается — проблема на сервере или в сети, а не в MobaXterm. Если другой клиент подключается нормально, стоит копать в сторону настроек самой сессии в MobaXterm.
На стороне сервера (при наличии доступа через консоль) проверьте состояние службы:
systemctl status sshd
journalctl -u sshd -n 50
В журнале ищите строки вида Connection closed by, fatal: или упоминания вашего IP — они прямо укажут, почему сервер завершил сессию. Также убедитесь, что на диске сервера есть свободное место: при переполненном разделе sshd может отклонять новые сессии сразу после логина.
Шаг 2. Проверка блокировок: fail2ban, firewall, hosts.deny
Частая причина мгновенных обрывов — ваш IP-адрес попал в бан. Сервис fail2ban блокирует адреса после нескольких неудачных попыток входа, и при этом соединение рвётся без объяснений на стороне клиента.
Что проверить на сервере:
- 🛡️ Список заблокированных адресов:
fail2ban-client status sshd— если ваш IP в списке, снимите бан командойfail2ban-client set sshd unbanip ваш_IP. - 🧱 Правила файрвола:
iptables -L -nили настройки ufw — убедитесь, что порт SSH не закрыт для вашего адреса. - 📄 Файлы
/etc/hosts.allowи/etc/hosts.deny— устаревшие записи там могут молча отклонять подключения. - ☁️ Облачный файрвол в панели хостинг-провайдера — у многих VPS-провайдеров есть отдельный сетевой фильтр поверх серверного.
⚠️ Внимание: если у вас динамический IP от провайдера, после перезагрузки роутера адрес может смениться — и старый бан перестанет действовать, но новый адрес тоже может попасть под блокировку при повторных ошибках пароля. Проверяйте учётные данные перед повторными попытками подключения.
Шаг 3. Настройка keepalive против обрывов при простое
Если сессия стабильно умирает после нескольких минут бездействия, виноват таймаут простоя — либо на сервере (ClientAliveInterval в конфигурации sshd), либо на промежуточном оборудовании: роутеры и NAT провайдера «забывают» неактивные TCP-соединения.
Решение — включить периодическую отправку пустых пакетов keepalive. В MobaXterm откройте настройки сессии: Settings → Configuration → SSH и отметьте опцию SSH keepalive. Также keepalive можно задать глобально через файл клиентской конфигурации OpenSSH:
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
Такая конфигурация отправляет пакет каждые 60 секунд и разрывает сессию только после трёх безответных попыток. Если есть доступ к серверу, зеркально можно настроить ClientAliveInterval в /etc/ssh/sshd_config — тогда сервер сам будет поддерживать канал. После правки конфигурации службу нужно перезапустить: systemctl reload sshd.
☑️ Чек-лист против обрывов при простое
Шаг 4. Диагностика на стороне клиента MobaXterm
Хотя ошибка почти всегда инициируется сервером, клиентские факторы исключать нельзя. Вам нужно последовательно проверить несколько моментов.
Во-первых, обновите MobaXterm до актуальной версии — в старых релизах встречались несовместимости с новыми алгоритмами шифрования на обновлённых серверах. Во-вторых, проверьте, не блокирует ли соединение антивирус или брандмауэр Windows: временно добавьте MobaXterm в исключения и повторите попытку. В-третьих, если подключение идёт через VPN или корпоративный прокси, попробуйте прямое соединение — промежуточные узлы нередко разрывают длинные SSH-сессии.
Полезно также посмотреть вывод терминала MobaXterm непосредственно перед обрывом: иногда там есть дополнительные строки, например упоминание отклонённого ключа или несовпадения алгоритмов.
Сравнение симптомов и вероятных причин
Свести наблюдения в таблицу помогает быстрее локализовать проблему:
| Симптом | Вероятная причина | Где проверять |
|---|---|---|
| Мгновенный обрыв при подключении | Бан в fail2ban, hosts.deny, ограничения sshd | Логи сервера, список заблокированных IP |
| Разрыв после ввода пароля | Переполненный диск, ошибки shell, права доступа | journalctl, свободное место, ~/.bashrc |
| Обрыв через несколько минут простоя | Таймаут NAT или ClientAliveInterval | Настройки keepalive на клиенте и сервере |
| Падение под нагрузкой | Нехватка памяти, лимиты MaxSessions | dmesg, OOM-killer, sshd_config |
| Обрыв только через VPN/прокси | Разрыв туннеля промежуточным узлом | Прямое подключение без VPN |
⚠️ Внимание: если в логах сервера видны записи OOM-killer (убийство процессов из-за нехватки памяти), обрывы SSH — лишь симптом. Добавление swap или оптимизация потребления памяти на сервере важнее любых настроек клиента.
Если ничего не помогло
Когда базовые проверки исчерпаны, остаются более глубокие варианты. Попробуйте подключиться с другого устройства и другой сети — это окончательно разделит проблему на «серверную» и «клиентскую» половины. Запустите SSH-клиент с максимальной детализацией: ssh -vvv покажет, на каком этапе рвётся канал.
На сервере можно временно запустить отладочный экземпляр sshd на альтернативном порту с выводом в консоль — так видно каждое решение демона в реальном времени. Этот метод требует прав администратора и аккуратности: не закрывайте основной рабочий сеанс, пока тестируете.
Как запустить sshd в отладочном режиме
Остановитесь на рабочем сеансе, не выходя из него, и выполните: /usr/sbin/sshd -d -p 2222. Затем подключитесь к порту 2222 — весь обмен будет выведен в консоль сервера. После диагностики завершите отладочный процесс через Ctrl+C.
Если сервер арендованный и доступа к логам нет, обратитесь в поддержку хостинг-провайдера — у них есть доступ к консоли и журналам, недоступным извне.
Частые вопросы
Почему MobaXterm рвёт соединение, а PuTTY к тому же серверу работает?
Различия обычно в настройках конкретной сессии: включённый X11-Forwarding, специфические алгоритмы шифрования или сохранённые туннели. Создайте в MobaXterm новую сессию с параметрами по умолчанию — если она работает, сравните настройки со старой.
Помогает ли переустановка MobaXterm?
Как правило, нет: ошибка генерируется сервером, а не клиентом. Переустановка оправдана только если другие SSH-клиенты с этого же компьютера работают, а MobaXterm — нет, и сброс настроек сессии не помог.
Сессия рвётся ровно через одинаковый интервал — что это?
Регулярный интервал — почти всегда признак таймаута: на сервере (ClientAliveInterval), на роутере или у провайдера. Включение keepalive на клиенте решает проблему в большинстве таких случаев.
Может ли ошибка быть вызвана неправильным паролем?
Неверный пароль обычно даёт ошибку аутентификации, а не обрыв соединения. Однако многократные неудачные попытки приводят к бану в fail2ban — и тогда последующие подключения начинают обрываться уже без запроса пароля.
Ошибка появляется только при работе через мобильный интернет. Почему?
Мобильные операторы активно используют NAT с короткими таймаутами неактивных соединений. Включите keepalive с интервалом 30–60 секунд и, по возможности, используйте функцию автоматического переподключения сессии.