Debian/Ubuntu: как исправить send-packets: Broken pipe и write failed в SSH, SCP, SFTP и rsync

Ошибки вида send-packets: Broken pipe, write failed: Broken pipe и client_loop: send disconnect: Broken pipe знакомы почти каждому, кто регулярно работает по SSH. Обычно они проявляются в один из трёх моментов: после долгого простоя терминала, во время передачи файлов через scp или sftp, либо в середине копирования через rsync -e ssh.

На Debian и Ubuntu такая проблема особенно заметна на серверах за NAT, в облачных сетях, через мобильный интернет, VPN или корпоративные межсетевые экраны. Сам текст ошибки часто вводит в заблуждение: кажется, будто сломался именно SSH, хотя на практике он лишь сообщает, что TCP-соединение уже было закрыто где-то по пути.

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

В статье разберём практический сценарий для Debian/Ubuntu: что означают разные варианты ошибки, как отличить idle-timeout от деградации сети, какие параметры ServerAliveInterval и ClientAliveInterval реально помогают и как аккуратно настроить SSH, scp, sftp и rsync без побочных эффектов.

Если SSH падает строго через одинаковый интервал простоя, почти всегда виноват не OpenSSH, а промежуточное сетевое устройство или NAT, которое выбрасывает тихое TCP-соединение из таблицы состояний.

Как проявляется проблема и что означают сообщения

Хотя формулировки похожи, контекст у них немного разный. Для диагностики это важно.

client_loop: send disconnect: Broken pipe

Обычно это сообщение показывает SSH-клиент при завершении уже испорченного соединения. Типовой сценарий: вы оставили терминал на 5–15 минут, вернулись, нажали Enter и получили разрыв. То есть канал умер раньше, а сообщение появилось только в момент новой отправки данных.

write failed: Broken pipe

Этот вариант чаще встречается при попытке записать данные в сокет, который уже закрыт. Причина та же: удалённая сторона недоступна или промежуточное устройство удалило состояние соединения. Для администратора это сигнал смотреть не только на SSH-конфиг, но и на весь сетевой тракт.

scp broken pipe, sftp broken pipe, rsync broken pipe ssh

Если ошибка возникает во время передачи файлов, круг причин становится шире. Кроме idle-timeout сюда добавляются обрывы канала под нагрузкой, проблемы с PMTU, нестабильный Wi-Fi, агрессивные stateful firewall, переподключение VPN, а иногда и зависание удалённого процесса из-за нехватки ресурсов.

Самые частые причины Broken pipe в Debian/Ubuntu

На практике причин немного, но они часто пересекаются.

Таймаут простоя на NAT, firewall или балансировщике

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

Нестабильная сеть клиента

Мобильный интернет, Wi-Fi с роумингом между точками доступа, перегруженный домашний роутер, VPN поверх нестабильного канала — всё это легко рвёт длинные соединения. Для пользователя это выглядит как проблема SSH, хотя сервер может быть полностью исправен.

Проблемы с MTU и PMTU black hole

Иногда мелкие пакеты проходят, а крупные — нет. Внешне это выглядит так: логин по SSH проходит, простые команды работают, а scp, sftp или rsync на больших данных зависают и затем падают. Особенно часто такое бывает при VPN, PPPoE, VXLAN и некоторых облачных сетях.

Ограничения или таймауты на сервере

Реже проблема действительно на стороне сервера: слишком агрессивные значения ClientAliveInterval, firewall, рестарт sshd, OOM, сетевые сбои после обновления ядра или драйвера. Но это обычно видно по журналам.

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

С чего начать диагностику

Самая частая ошибка — сразу менять keepalive наугад. Намного полезнее сначала классифицировать симптом.

Шаг 1. Определите, когда возникает обрыв

• Только после простоя терминала — почти наверняка нужен keepalive.
• Во время активной передачи файлов — смотрим сеть, MTU, качество канала и логи сервера.
• И при простое, и под нагрузкой — возможно, причин несколько.
• Только в одной конкретной сети или через один VPN — проблема, скорее всего, вне сервера.

Шаг 2. Запустите SSH с подробной отладкой

На Debian/Ubuntu начните с обычного -v, а если этого мало — используйте -vvv.

ssh -vvv user@server

Если проблема проявляется после простоя, оставьте сессию, дождитесь обрыва и посмотрите последние строки. Полезны сообщения о keepalive, таймаутах и завершении транспорта.

Для scp и sftp логика та же:

scp -v bigfile.tar user@server:/tmp/
sftp -v user@server

Для rsync удобно включить и его подробный вывод, и SSH-отладку:

rsync -av --progress -e "ssh -vvv" ./data/ user@server:/backup/data/

Шаг 3. Проверьте журналы на сервере

На Debian и Ubuntu сообщения OpenSSH обычно попадают в journald. Смотрите журнал сервиса и общесистемные сообщения за момент обрыва.

sudo journalctl -u ssh --since "30 min ago"
sudo journalctl -xe --since "30 min ago"

Если в журнале пусто, это уже полезная подсказка: соединение могло исчезнуть где-то по пути, и сервер не успел зарегистрировать нормальное завершение сессии.

Шаг 4. Проверьте другую сеть

Это один из самых недооценённых тестов. Попробуйте подключиться по кабелю вместо Wi-Fi, временно отключить VPN, использовать мобильный интернет или сделать SSH с другого узла в том же дата-центре.

Если Broken pipe исчезает после смены сети, бессмысленно долго править сервер: источник проблемы находится на стороне канала или промежуточного оборудования.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

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

Как настроить keepalive на клиенте SSH

Если SSH простаивает и стабильно отваливается через одинаковый интервал, начинать лучше с клиентских keepalive. Именно они чаще всего спасают от idle-timeout на NAT и firewall.

Нужные параметры клиента:

• ServerAliveInterval — как часто клиент отправляет keepalive-запрос серверу;
• ServerAliveCountMax — сколько подряд пропусков ответа допускается до разрыва.

Для пользователя настройка обычно делается в ~/.ssh/config. Глобально — в /etc/ssh/ssh_config.

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

На практике это значит, что клиент будет отправлять keepalive каждые 60 секунд и разорвёт сессию только после трёх неудачных попыток подряд. Для большинства сценариев это разумная стартовая точка.

Безопасная базовая настройка для большинства рабочих станций и серверов — ServerAliveInterval 60 и ServerAliveCountMax 3. Этого обычно хватает, чтобы пережить типичные idle-timeout без лишнего шума в канале.

Когда нужен ClientAliveInterval на сервере

В поиске часто советуют сразу править /etc/ssh/sshd_config и задавать ClientAliveInterval. Это полезно, но важно понимать назначение этих параметров.

• ClientAliveInterval — как часто сервер проверяет, жив ли клиент;
• ClientAliveCountMax — сколько пропусков подряд допускается.

Такие настройки полезны для очистки зависших сессий и в некоторых сетях тоже помогают удержать соединение. Но если рвётся обычный SSH-клиент после простоя, чаще первым делом помогает именно ServerAliveInterval на клиенте.

Пример умеренной серверной настройки:

ClientAliveInterval 60
ClientAliveCountMax 3

После изменения обязательно проверьте конфигурацию и только потом перечитайте сервис:

sudo sshd -t
sudo systemctl reload ssh

Если вы параллельно разбираетесь с фильтрацией пакетов или подозреваете проблемы на firewall, полезно свериться с материалом про настройку iptables и nftables в Docker-сценариях: там хорошо видны типичные ловушки в stateful-правилах и обработке соединений.

Быстрые одноразовые тесты без правки конфигов

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

ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@server

Для scp:

scp -o ServerAliveInterval=60 -o ServerAliveCountMax=3 archive.tar user@server:/tmp/

Для sftp:

sftp -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@server

Для rsync:

rsync -av --progress -e "ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3" ./data/ user@server:/backup/data/

Если с этими опциями проблема исчезает, вы почти наверняка имеете дело с idle-timeout, а не с неисправностью OpenSSH.

Если Broken pipe возникает именно на SCP, SFTP или rsync

Здесь уже нужно смотреть шире. Keepalive полезен, но не всегда достаточен.

Проверьте MTU и подозрение на PMTU black hole

Характерный признак такой: SSH логинится, короткие команды выполняются, маленькие файлы копируются, а большие зависают или обрываются. Особенно если между сторонами есть VPN, туннель или нестандартная сеть.

Косвенно это можно проверить пингом с запретом фрагментации, подбирая размер полезной нагрузки:

ping -M do -s 1472 server_ip
ping -M do -s 1400 server_ip
ping -M do -s 1360 server_ip

Если большие размеры не проходят, а меньшие проходят стабильно, стоит проверить MTU на интерфейсах, VPN и виртуальной сети. В этом случае Broken pipe — уже следствие сетевой проблемы.

Если соединение идёт через туннель, пригодится и материал про site-to-site VPN на WireGuard: там хорошо видно, как MTU и маршрут влияют на стабильность длинных SSH-сессий.

Посмотрите retransmit и ошибки TCP

На клиенте и сервере полезно открыть статистику сокетов во время воспроизведения проблемы:

ss -ti dst server_ip
ss -ti sport = :22
netstat -s | grep -i retrans

Рост retransmission, reset или timeout — сильный аргумент в пользу сетевого сбоя, а не ошибки в SSH-конфиге.

Проверьте нагрузку на сервере

Иногда кажется, что рвётся SSH, а на самом деле сервер в этот момент упирается в диск, память или CPU. При больших копированиях это особенно заметно.

uptime
free -m
iostat -xz 1 5
vmstat 1 5
df -h

Если диск перегружен, начинается сильный I/O wait, а сеть параллельно уходит в retransmit, снаружи это будет выглядеть точно так же — как очередной Broken pipe.

Для таких задач с длинными передачами и бэкапами удобнее использовать виртуальный хостинг или выделенный серверный стек только там, где это действительно подходит по нагрузке и доступу; если нужен полный контроль над SSH и сетью, практичнее смотреть в сторону VDS.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Особенности rsync по SSH

rsync часто фигурирует в жалобах отдельно, потому что задачи с ним долгие: бэкапы, деплой, миграции, копирование медиаархивов. Чем дольше живёт SSH-канал, тем выше шанс поймать таймаут простоя или кратковременную деградацию канала.

Базовая практика здесь простая:

• включить keepalive у SSH-транспорта;
• добавить прогресс или статистику, чтобы понимать, на чём всё оборвалось;
• перезапускать передачу — rsync хорошо дозаливает недокопированное;
• не включать агрессивное сжатие без необходимости, если CPU слабый или канал нестабилен.

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

rsync -av --partial --append-verify --progress -e "ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3" /src/ user@server:/dst/

Ключи --partial и --append-verify не устраняют причину Broken pipe, но позволяют не начинать загрузку больших файлов с нуля после каждого обрыва.

Что ещё проверить в Debian/Ubuntu

Параметры TCP keepalive ядра

Иногда вспоминают системные параметры вроде net.ipv4.tcp_keepalive_time. Они существуют, но для SSH-проблемы после простоя обычно менее удобны, чем настройки OpenSSH, потому что системный TCP keepalive по умолчанию довольно медленный. Менять его для всей системы стоит только если вы понимаете последствия для других приложений.

sysctl net.ipv4.tcp_keepalive_time
sysctl net.ipv4.tcp_keepalive_intvl
sysctl net.ipv4.tcp_keepalive_probes

Если проблема локализована именно в SSH, разумнее начать с ServerAliveInterval и ClientAliveInterval, а не с глобального TCP-тюнинга.

UFW, nftables и облачный firewall

Если соединение рвётся на ровном месте и только снаружи, проверьте не только локальный firewall сервера, но и внешний: security groups, правила у провайдера, политики на гипервизоре или роутере. Иногда причина — в коротком idle-timeout или слишком агрессивной очистке state table.

VPN и jump host

Если обрыв происходит при доступе через VPN или bastion, проблема может быть вообще не на целевом сервере. Диагностировать нужно весь путь целиком: клиент, VPN, jump host и только потом конечный узел.

Рабочие конфигурации для типовых случаев

Ниже — несколько практических профилей, которые можно взять как стартовую точку.

Для ноутбука администратора с нестабильным интернетом

Host *
    ServerAliveInterval 30
    ServerAliveCountMax 4

Подходит для частой работы через Wi-Fi, мобильную сеть и VPN. Трафика немного, зато сессии заметно лучше переживают idle-timeout.

Для обычного сервера без экзотики

Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3

Это хороший компромисс между устойчивостью и количеством keepalive-пакетов.

Для серверной стороны, если нужно убирать мёртвые сессии

ClientAliveInterval 120
ClientAliveCountMax 2

Такой вариант помогает не держать зависшие подключения бесконечно. Но если задача — спасти клиента от простоя за NAT, начинать всё равно лучше с клиентских параметров.

Типичные ошибки при попытке починить Broken pipe

• Менять только сервер, не проверяя клиентские ServerAliveInterval.
• Ставить слишком маленькие интервалы keepalive без причины.
• Игнорировать VPN, домашний роутер, офисный firewall и облачную сеть.
• Путать idle-timeout с MTU-проблемой: в первом случае рвётся после простоя, во втором — под нагрузкой и на больших передачах.
• Не смотреть журнал ssh и отладку ssh -vvv.
• Считать, что если страдает rsync, то виноват именно он, а не SSH-транспорт под ним.

Краткий runbook: что делать по порядку

1. Понять, обрыв происходит после простоя или во время передачи данных.
2. Запустить ssh -vvv и воспроизвести проблему.
3. Проверить журналы через journalctl -u ssh.
4. Протестировать клиентские опции ServerAliveInterval и ServerAliveCountMax без изменения глобальных конфигов.
5. Если ломаются scp, sftp или rsync на больших файлах, проверить MTU и retransmit.
6. Исключить влияние VPN, Wi-Fi, NAT и внешнего firewall.
7. Только после этого закрепить постоянные настройки в ~/.ssh/config или sshd_config.

Итог

Ошибки send-packets: Broken pipe, write failed: Broken pipe, scp broken pipe, sftp broken pipe и rsync broken pipe ssh почти никогда не означают сломанный SSH в буквальном смысле. Обычно это симптом: соединение уже умерло где-то между клиентом и сервером, а OpenSSH лишь сообщил о последствиях.

Если обрывы происходят после простоя, первым делом проверяйте ServerAliveInterval и при необходимости ClientAliveInterval. Если проблема возникает во время передачи файлов, обязательно смотрите на MTU, качество сети, retransmit и журналы сервера. Такой порядок почти всегда быстрее, чем бессистемно менять десяток параметров подряд.

Практический минимум, который стоит запомнить: для большинства случаев достаточно начать с ServerAliveInterval 60 и ServerAliveCountMax 3, протестировать поведение, а уже затем решать, нужно ли менять серверные параметры или искать проблему глубже в сети.