Что я могу сделать, чтобы настроить SSH как на клиенте, так и на серверах, чтобы предотвратить Write Failed: broken pipe ошибки? Это часто происходит, если вы переводите клиентский компьютер в спящий режим и возобновляете работу позже.
Я пробовал это в /etc/ssh/ssh_config для Linux и Mac:
Host *ServerAliveInterval 120Именно так часто, в секундах, он должен отправлять сообщение keepalive на сервер. Если это не сработает, то приучите обезьяну нажимать enter каждые две минуты во время работы.
Вы могли бы установить либо ServerAliveInterval в /etc/ssh/ssh_config клиентской машины или ClientAliveInterval в /etc/ssh/sshd_config серверной машины. Попробуйте уменьшить интервал, если вы все еще получаете сообщение об ошибке.
Конфигурация для одного пользователя может быть задана в файле ~/.ssh/config как на стороне сервера, так и на стороне клиента. Убедитесь, что файл имеет правильные разрешения chmod 644 ~/.ssh/config.
Сеансы SSH могут прерываться по многочисленным и, возможно, неизбежным причинам.
Полезная утилита, которую можно использовать для устранения проблем, вызванных этим, называется screen. Screen - это мощная утилита, которая позволяет вам управлять несколькими терминалами, которые будут работать независимо от сеанса ssh. Например, если вы запустите screen в сеансе ssh вы увидите открытый новый терминал, и вы сможете использовать его для выполнения заданий. Допустим, ваш сеанс ssh завершается в процессе. Бегущий screen -d затем screen -r откроется последняя сессия, и вы сможете продолжить оттуда. Убедитесь, что вы прочитали часть документации перед его использованием.
Конфигурация клиента
Попробуйте создать файл:
~/.ssh/configДобавьте содержимое:
Host * ServerAliveInterval 30 ServerAliveCountMax 5Теперь подключитесь по ssh к своему серверу и посмотрите, устранена ли ваша проблема. Опция ClientAliveInterval полезна только при настройке ssh-сервера (он же sshd), она ничего не меняет на стороне ssh-клиента, поэтому не используйте ее в приведенном выше файле конфигурации.
Это отправит сигнал hello-are-you-there на сервер, если за предыдущие 30 секунд не было получено ни одного пакета (как указано выше). Однако, если количество последовательных сигналов hello-are-you-there достигнет ServerAliveCountMax, ssh отключится от сервера. Это значение по умолчанию равно 3 (таким образом, 3 * 30 = 90 секунд без активности сервера), увеличьте его, если оно соответствует вашим потребностям. В файле .ssh /config есть еще много параметров конфигурации, и вы могли бы прочитать:
Использование конфигурационного файла SSH
Для получения дополнительной информации о других вариантах. Возможно, вы не захотите применять это к каждому серверу, к которому вы подключаетесь в этом примере. Или ограничьте его только определенным сервером, заменив строку Host * с Host <IP> (замените на IP-адрес, см. справочную страницу ssh_config).
Конфигурация сервера
Точно так же вы можете сказать серверу, чтобы он был нежен с вашими клиентами. Конфигурационный файл представляет собой /etc/ssh/sshd_config.
ClientAliveInterval 20ClientAliveCountMax 5Вы можете либо отключить его, установив ClientAliveInterval к 0 или подправить ClientAliveInterval и ClientAliveCountMax чтобы установить максимальную неактивность ssh-клиента без ответа на запросы. Одним из преимуществ этих настроек по сравнению с TCPKeepAlive является то, что сигналы передаются по зашифрованным каналам, поэтому вероятность подделки меньше.
Я удаленно обновляю сервер Ubuntu с lucid до точного и потерял ssh-соединение в середине обновления с сообщением "Ошибка записи. Сломанная труба". ClientAliveInterval и ServerAliveInterval ничего не сделали. Решение состоит в том, чтобы включить параметры TCPKeepAlive в клиентском ssh:
TCPKeepAlive yesв
/etc/ssh/ssh_configНадеюсь, это поможет
Для клиента отредактируйте свой ~/.ssh/config (или /etc/ssh/ssh_config) файл следующим образом:
Host * TCPKeepAlive yes ServerAliveInterval 120Tcpподдержать - Указывает, должна ли система отправлять сообщения TCP keepalive другой стороне. Если они будут отправлены, то обрыв соединения или сбой одной из машин будут должным образом замечены. Однако это означает, что соединения будут отключены, если маршрут временно отключен, и некоторые люди находят это раздражающим (значение по умолчанию - "да").
ServerAliveИнтервал - Устанавливает интервал ожидания в секундах, после которого, если с сервера не было получено никаких данных, ssh(1) отправит сообщение по зашифрованному каналу для запроса ответа от сервера. Значение по умолчанию равно 0, что указывает на то, что эти сообщения не будут отправляться на сервер.
Для сервера отредактируйте свой /etc/ssh/sshd_config как:
ClientAliveInterval 600ClientAliveCountMax 0Если вы хотите, чтобы ssh-клиент автоматически завершал работу (тайм-аут) через 10 минут (600 секунд).
ClientAliveCountMax – Это указывает на общее количество сообщений checkalive, отправленных ssh-сервером без получения какого-либо ответа от ssh-клиента. Значение по умолчанию равно 3.
ClientAliveИнтервал – Это указывает время ожидания в секундах. Через x секунд ssh-сервер отправит клиенту сообщение с запросом ответа. Значение Deafult равно 0 (сервер не будет отправлять сообщение клиенту для проверки.).
Смотрите также: Какие есть варианты ServerAliveInterval и ClientAliveInterval в sshd_config делать, точно?
Я просто обожаю Моша. Я часто подключаюсь к серверу по ssh, закрываю свой ноутбук и иду в кафе, открываю его и продолжаю, как будто ничего не изменилось.
Mosh (мобильная оболочка)
Приложение удаленного терминала, позволяющее роуминг, поддерживает прерывистое подключение, и обеспечивает интеллектуальный местное эхо и редактирование строк пользовательских нажатий клавиш.
Mosh - это замена SSH. Он более надежный и отзывчивый, особенно по Wi-Fi, сотовой связи и междугородним линиям связи.
Mosh - это бесплатное программное обеспечение, доступное для GNU / Linux, FreeBSD, Solaris, Mac OS X и Android.
Что касается меня, то я получал Write failed: Broken pipe даже когда я активно печатал в vim или в командной строке. Я тоже некоторое время не мог просматривать Интернет локально. (Я удаленно подключался к Ubuntu с помощью терминала.)
Другие пользователи моей сети транслируют много видео с Netflix и других мест. Я не могу это доказать, но я подозреваю, что это проблема с интернет-провайдером или маршрутизатором. Например, Verizon и Netflix указывают друг на друга пальцами из-за сетевых проблем своих клиентов.
Если у вас есть коммутируемое соединение и вы транслируете видео или музыку с одновременным подключением по SSH или telnet, в какой-то момент вы неизбежно получите сообщение о сбое канала. Обновление моего широкополосного пакета интернет-провайдеров, казалось, сделало мое прерывистое соединение менее частым.
Я опубликовал свой ответ здесь, так как это не была виртуальная машина Ubuntu.
ssh -o IPQoS=throughput user@hostУ меня есть скрипт на удаленном сервере, который, похоже, никогда не выходит из строя, независимо от конфигурации SSH-клиента или сервера.
#!/bin/bashwhile true; do date; sleep 10; done;Сохраните это для какого-нибудь dummy.sh файл и быстро запустите его, прежде чем свернуть окно или отойти от него. Он будет продолжать печатать текущую отметку времени на сервере и поддерживать ваше соединение до тех пор, пока соединение не будет прервано по какой-либо другой причине. Когда вы вернетесь к этому терминалу, просто нажмите CTRL + C и продолжайте работать.
Вы можете добавлять эти аргументы каждый раз, когда вызываете ssh: -o ServerAliveInterval=15 -o ServerAliveCountMax=3
Вам не нужно редактировать конфигурационные файлы /etc /ssh /*, если вы это сделаете.
Вы можете создать псевдоним bash, функцию или скрипт, чтобы упростить это.
Например, эти функции bash вы можете добавить в свой файл .bashrc, do_ssh используется вручную для включения keepalives. do_ssh_pty используется в скриптах для установки pty и предотвращения подсказок.
do_ssh() { ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=3 $*}do_ssh_pty() { ssh -tt -o "BatchMode=yes" -o "StrictHostKeyChecking=no" -o ServerAliveInterval=15 -o ServerAliveCountMax=3 $*}Сейчас do_ssh user@host может быть использован или do_ssh user@host <args> <command> и keepalives будет активен.
@DavidL тебе следует получше прочитать вопросы, прежде чем разглагольствовать. Ваша проблема не такая, как у операционного директора, который четко упоминает о переводе компьютера в спящий режим. Который, кстати, касается только одного из ответов (“mosh”), и он был опубликован через 2 года после вопроса. Однако другие ответы делают следующее лучшее, а именно предлагают решения для случаев, которые можно решить проще, как у вас. Успокойся, не будь таким напряженным, разглагольствования здесь ни к чему хорошему не приводят…
На самом деле ничего особенного. Сеанс был прерван, и безопасность сеанса была поставлена под угрозу. Если вы не переводите компьютер в спящий режим, вы можете установить время ожидания для клиента, чтобы он передавал на сервер сердцебиение “Поддерживать жизнь”, но если система переходит в спящий режим, то ничего нельзя сделать.
Вы, люди, ошибаетесь: у меня есть ДВА настольных клиентских компьютера, подключенных к ОДНОМУ и ТОМУ ЖЕ серверу. Один из них - ubuntu 12.10, Quantal, чей SSH-клиент работает хорошо и поддерживает соединение в течение нескольких часов. Другой - Ubuntu 14.10, утопический, просто в стороне от другого и при новой установке; через пару минут он блокирует себя этим сообщением. Остальные сетевые функции на компьютере не прерываются. Так что нет, это не сетевая проблема и не проблема сервера, а конкретная проблема программного обеспечения SSH-КЛИЕНТА, которую МОЖНО решить, вопреки тому, что “darkdragan” осмеливается сказать, что “ничего нельзя сделать”.
В этом случае я ищу что-то, что позволило бы мне повторно инициировать прерванное ssh-соединение (вероятно, на основе кода выхода) и восстановить с помощью "экрана`?
И действительно, как я уже сказал: люди слишком много болтают, когда говорят “ничего нельзя сделать”, как и осмелился @darkdragn. Я прочитал ответ Арама Кочаряна и применил его: 20 минут назад… Я понял, что в моем старом Quantal Ubuntu 12.10 я применил эту инструкцию в этом файле [я только что проверил] два года назад, и это было причиной стабильности там. Я сделал это здесь, и за последние 20 минут соединение с тех пор было стабильным. Поэтому, пожалуйста, люди: воздерживайтесь, когда осмеливаетесь думать, что “ничего нельзя сделать”, и еще больше воздерживайтесь, когда пытаетесь оставить это сообщение другим людям.
@Davidl Согласен с тем, что отрицание может раздражать, особенно с позиции невежества.
Тем не менее, также кажется, что вы восприняли это немного близко к сердцу (иначе говоря, немного грубо). проблема темного дракона имела в виду только хорошее
Та же проблема в сети, когда два устройства с одинаковым адресом.
Выключите один из них, и проблема будет решена.
Сеансы SHH чередуют ключи шифрования с течением времени, чтобы предотвратить длительные атаки методом перебора. Переход в режим ожидания / возобновления приведет к нарушению этой безопасности и соединения.
Ничто так не приятно, как следующая ситуация. Человек, говорящий: “это невозможно сделать / Ничего нельзя сделать”, получает ответ или прерывается кем-то, говорящим: “Смотрите… Это сделано, и это было легко” @darkdragn