packet_write_wait Сломанная труба, даже не работающая?

Эта кровавая ошибка заставляет мою головную боль усиливаться с каждым днем. Я никогда не встречал такой ситуации, как в этот раз.

Что ж, после того, как я успешно прошел аутентификацию в SSH, выполняя несколько вещей, мое SSH-соединение внезапно обрывается !!?

Вот мое сообщение об ошибке: packet_write_wait: Connection to XXX.XX.XX.XXX: Broken pipe

Я хотел, чтобы мое сообщение об ошибке выглядело так: Write Failed: broken pipeмного, поверь мне!

Я пробовал тонны разрешения в Интернете, как добавлено ServerAliveInterval, ServerAliveCountMax, ClientAlive ....

Кто-то сказал: «Преврати свой TCPKeepAlive в нет», добавил ServerAlive, бла-бла-идиот. Я сделал это тоже, но все еще та же ошибка.

Мне не повезло до этого момента.

Любая помощь будет оценена.

Уважаемые читатели 2018 года и позже,

Позвольте мне показать вам комментарий от MelBurslan,

Если вы находитесь в корпоративной среде, узнайте у администраторов брандмауэра и посмотрите, обновляли ли они правила и / или перезапускали ли брандмауэр после каких-либо изменений, когда это происходит. Если это происходит с вашим личным сервером, вам нужно предоставить больше информации о том, что вы делали на стороне сервера sshd, когда это произошло. Сломанный канал обычно означает, что по какой-то причине произошло отключение от сети.

Так что в основном, если вы пытаетесь использовать ssh username@0.0.0.0через VPN (корпоративная среда). Тогда эта ошибка должна быть с вами снова и снова.

Единственное решение, которое я нашел до сих пор, это mobile-shell . Спасибо, кто создал это.

Вам нужно будет установить mosh-serverв своей цели (сервер, на котором вы хотите ssh'ed) и mosh-clientна хост-машине.

Я думаю, что он автоматически переподключится, когда ваши пакеты будут потеряны.

Счастливого ssh'ing!

Я обнаружил, что это была проблема с опцией IPQoS при настройке гостевой системы VMware. На ВМ я установил значение ~ / .ssh / config для IPQoS из значения по умолчанию «IPQoS af21 cs1», представляющего собой данные с низкой задержкой для интерактивного первого и меньшие усилия для неинтерактивного для второго. Установка нового значения для af21 была моим решением:

Host *
     IPQoS throughput

Работал для меня, иначе да, MoSH также работает, но mosh не обрабатывает мою настройку Proxy удобным способом, поэтому я придерживаюсь команд ProxyJump в

Во-первых, убедитесь, что ваша проблема не связана с этим .

Если нет и проблема все еще присутствует, читайте дальше.

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

Как указано, игра с параметрами SSH KeepAlive или параметрами TCP ядра (вкл / выкл TCPKeepAlive) не решает проблему.

Поиграв с usb в драйверы Ethernet и дамп TCP, я понял, что проблема связана с ядром 4.8. Я переключил источник (отправляющая сторона) на 4.4 LTS, и проблема исчезла (rsync, scp снова работали хорошо). Сторона назначения может остаться на 4.8, если хотите, в моем случае это работало (проверено).

С технической стороны, мы можем немного сузить проблему благодаря свалке проволоки ниже, которую я сделал. Мы можем видеть, что канал TCP протокола SSHv2 сбрасывается (флаг RST TCP установлен в 1), что приводит к прерыванию соединения. Я еще не знаю причину RST. Для этого мне нужно сделать несколько пополам с 4.8.1 до 4.8.11.

Я не говорю, что ваша проблема связана именно с ядром 4.8, но это не так. дата, когда вы опубликовали свой вопрос / сообщение, вы, возможно, использовали версию ядра, которая была действительно глючной.

Ответили изначально на StackOverflow .

ssh -o IPQoS=throughput user@{ip}

Откройте файл ssh.config на целевом сервере с помощью следующей команды:

sudo nano /etc/ssh/ssh.config

Добавьте строки ниже в конце этого файла

ClientAliveInterval 300

ClientAliveCountMax 2

нажмите Ctrl + o и введите.

перезагрузка sudo

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