Почему неактивные сеансы SSH завершаются сообщением «Ошибка записи: сломанный канал»?

Question

Я знаю, что это общая проблема с известным решением. Быстрый веб-поиск приводит ко многим результатам, которые указывают на параметры ServerAliveInterval (или, реже, ClientAliveInterval стороне сервера ). Установка одного из них на произвольное значение, такое как 15, 60 или 120, решит проблему со сломанной трубой.

У меня вопрос почему? Почему это происходит в первую очередь? Кто закрывает розетку?

У меня есть сомнения по поводу того, что ОС прерывает соединение из-за неактивности, учитывая тот факт, что по умолчанию включена опция TCPKeepAlive , которая заставляет отправлять сообщения поддержки активности TCP, чтобы обнаружить отключение клиентов в автономном режиме. Поэтому ОС все равно не увидит соединение неактивным.

В этом случае, это сам sshd , который синхронизирует их? И если так, то почему этот тайм-аут не задокументирован или не настраивается? А если для поддержания SSH-соединений необходимы открытые сообщения уровня приложения, то почему они не включены по умолчанию?

Эти вопросы всегда пропускаются, когда эта проблема появляется на дискуссионных форумах. Может кто-нибудь пролить некоторый свет на это?

Answer 1

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

В любом случае, если вам нужно что-то более надежное для таких соединений, я рекомендую mosh. Это очень легко настроить, и у вас не должно возникнуть проблем с отключением. На самом деле, вы даже можете переключать IP-адреса, и он сразу же вернется туда, где вы были, без особых проблем. Mosh использует UDP, что позволяет такое поведение.

Что касается того, как он работает, он использует SSH для установления соединения с сервером, на котором работает mosh-server . Затем программа прослушивает порт UDP (по умолчанию около 60000), чтобы клиент мог подключиться к mosh-client . Это означает, что единственная конфигурация, которую вам нужно сделать, - это простая переадресация порта.

Надеюсь, это поможет.

Answer 2

Кто закрывает розетку?

Никто не закрывает "сокет", т.е. ни клиент, ни сервер. Проблема с соединением обычно вызывается фильтрами пакетов с отслеживанием состояния между сторонами связи. Такие фильтры пакетов используются в брандмауэрах, а также в простых маршрутизаторах SoHo, где они необходимы для обработки состояний для NAT, который является типичным способом предоставления доступа в Интернет для нескольких внутренних систем за одним и тем же внешним IP-адресом.

Такие фильтры пакетов с состоянием создают состояние для каждого нового соединения и разрушают его при закрытии соединения. Это означает пакеты SYN/FIN с TCP-соединениями, такими как ssh. Эти состояния занимают память, поэтому фильтр пакетов может поддерживать только ограниченное количество состояний одновременно. Поэтому он удалит эти состояния после некоторого времени бездействия (т.е. без пакетов для этого соединения).

Если в TCP-соединении нет активности, пакеты не будут отправлены. Это верно и для SSH. Через некоторое время бездействия состояние в фильтре пакетов будет удалено. Если какая-либо сторона соединения затем отправит больше пакетов после бездействия, в фильтре пакетов не будет состояния и будет выпущен пакет RST. Это приводит к "Сломанной трубе".

Параметр TCPKeepAlive в SSH включает параметр TCP keepalive, который заставляет уровень TCP регулярно отправлять пустые пакеты (т. Е. Пакет TCP без полезной нагрузки данных) во время бездействия. Таким образом, фильтр пакетов сохраняет состояние открытым.