Write failed broken pipe что значит

Как предотвратить «Ошибка записи: сломанный канал» в SSH-соединении?

Что я могу сделать, чтобы настроить SSH на клиенте и на серверах для предотвращения Write Failed: broken pipe ошибок? Это часто происходит, если вы спите на своем клиентском компьютере и возобновите работу позже.

Я пробовал это /etc/ssh/ssh_config для Linux и Mac:

Это как часто, в секундах, он должен отправлять сообщение keepalive на сервер. Если это не сработает, научите обезьяну нажимать ввод каждые две минуты, пока вы работаете.

Вы можете установить либо ServerAliveInterval в /etc/ssh/ssh_config клиентской машине или ClientAliveInterval в /etc/ssh/sshd_config серверной машине. Попробуйте уменьшить интервал, если вы все еще получаете ошибку.

Конфигурация для одного пользователя может быть задана в файле

/.ssh/config как на стороне сервера, так и на стороне клиента. Убедитесь, что файл имеет правильные разрешения chmod 644

Сеансы SSH могут прерваться из-за многочисленных и, возможно, неизбежных причин.

Полезная утилита, которая может использоваться для смягчения проблем, вызванных этим, называется screen . Screen — мощная утилита, которая позволяет вам управлять несколькими терминалами, которые будут работать независимо от сеанса ssh. Например, если вы запустите screen сеанс ssh, вы увидите, что новый терминал открыт, и вы можете использовать его для запуска заданий. Допустим, ваша сессия SSH умирает в процессе. Запуск screen -d затем screen -r будет вновь открыть последнюю сессию , и вы будете в состоянии продолжить оттуда. Убедитесь, что вы прочитали часть документации, прежде чем использовать ее.

Конфигурация клиента

Попробуйте создать файл:

Теперь зайдите на ваш сервер и посмотрите, исправлена ​​ли ваша проблема. Параметр ClientAliveInterval полезен только при настройке сервера ssh (он же sshd), он ничего не меняет на стороне клиента ssh, поэтому не используйте его в приведенном выше файле конфигурации.

Это отправит на сервер сигнал приветствия, если вы не получили пакетов в течение предыдущих 30 секунд (как указано выше). Однако, если число последовательных сигналов приветствия вас достигнет ServerAliveCountMax, тогда ssh отключится от сервера. Это значение по умолчанию равно 3 (поэтому 3 * 30 = 90 секунд без активности сервера), увеличьте его, если оно соответствует вашим потребностям. В файле .ssh / config есть много других параметров конфигурации, и вы можете прочитать:

Для получения дополнительной информации о других вариантах. Возможно, вы не захотите применять это к каждому серверу, к которому вы подключаетесь, к примеру. Или ограничьте его только определенным сервером, заменив строку Host * на Host (замените IP-адресом, см. Справочную страницу ssh_config).

Конфигурация сервера

Точно так же вы можете сказать серверу быть осторожным с вашими клиентами. Файл конфигурации есть /etc/ssh/sshd_config .

Вы можете либо отключить его, установив ClientAliveInterval на 0 или настроить ClientAliveInterval и ClientAliveCountMax установить максимальную SSH клиента бездеятельность , не отвечая на зондах. Одно из преимуществ этих настроек по сравнению с TCPKeepAlive заключается в том, что сигналы отправляются по зашифрованным каналам, поэтому вероятность их подделки меньше.

Источник

Fixing Broken Pipe Error With SSH Connection

If you use SSH to connect to remote Linux servers, you’ll notice that if you keep your SSH session inactive for some time and then try to use it again, the SSH session disconnects with an error message like this:

On some systems, it will display ‘Write failed: Broken pipe’ or ‘Connection closed by remote host’.

Let’s see what causes this error and how to go about keeping your SSH connection alive.

Fixing broken pipe error with SSH

As you may have guessed, the SSH connection is closed because of inactivity. There is no set value but it usually around 5 minutes or so.

What you can do to avoid the SSH session disconnection is to send an ‘alive message’ either from the server to client ( ClientAliveInterval ) or from client to server ( ServerAliveInterval ) at certain time interval.

This way, you keep the SSH session alive because there is a communication between the client and server and the server understands that client is still there.

Now, there are two ways to do that. Either you send the alive message from the client to the server or from the server to the client.

• If you connect to multiple servers via SSH, set it on your machine.
• If you are a sysadmin and several of users complain about frequent SSH connection disconnect, you may set it on the server.

Method 1: Client side SSH configuration change

Let’s say you want to keep your SSH connection alive with up to 10 minutes (600 seconds) of idle time.

While connecting to the remote Linux system through SSH, you can mention the ServerAliveInterval value like this:

Now, this thing work but manually entering this option each time you connect to the server is tiresome. Why not make it permanent?

I hope you are aware of the SSH config files. On the client side, you can take advantage of it to set certain SSH parameters for specific connections or all of them. I have explained SSH config file in detail here.

First, make sure that you have the ssh config file. If not create it:

It is important to give it the correct file permissions otherwise you’ll have permission denied error while connecting via SSH.

Use the chmod command and add the following file permission to it:

If you’re feeling lazy or don’t want to go in detail, use this command to set the alive interval to 600 seconds (10 minutes):

This will set the ServerAliveInterval value to 10 minutes for all SSH connection you’ll use. Give it a try if you want to.

If you want to make it more proper, you should add it like this:

Method 2: Server side SSH config change

The SSH config file for the server is usually located at /etc/ssh/sshd_config.

If you open this file, you’ll find two parameters of interest here:

• ClientAliveInterval : This is the inactivity time period after which the server will send an alive message to the ssh connected client.
• ClientAliveCountMax : This is the number of attempts the server will make to send the alive message.

Say, you set ClientAliveInterval to 200 seconds and ClientAliveCountMax to 3. This means the server will send alive message after 200 seconds. If there is no activity from the client, it will again send an alive message at 400 seconds. No response/activity from the client and another alive message is sent at 600 seconds. After this (600 seconds) the SSH connection is disconnected.

You can edit the /etc/ssh/sshd_config file in your favorite terminal based text editor like Vim. Look for ClientAliveInterval and ClientAliveCountMax entries. Remove the # key at the beginning of the lines and give them the appropriate value.

Save and exit the file.

Please do not set the SSH connection timeout to several hours. That would be a waste of resources.

I hope this tutorial helped you to fix the broken pipe error issue with SSH connection. Your feedback is welcome.

Источник

Write failed : broken pipe

I have a headless Ubuntu server. I ran a command on the server (snapraid sync) over SSH from my Mac. The command said it would take about 6 hrs, so I left it over night.

When I came down this morning, the Terminal on the Mac said: «Write failed: broken pipe»

I’m not sure if the command executed fully. Is this a timeout issue? If so, how can I keep the SSH connection alive overnight?

10 Answers 10

This should resolve the problem for Mac osX version: 10.8.2

Or, if you want it to be a global change in the SSH client, to this file

«ServerAliveInterval 120» basically says to «ping» the server with a NULL packet every 120s, and «TCPKeepAlive no» means to not set the SO_KEEPALIVE socket option (since you shouldn’t need it with ServerAliveInterval already set, and apparently it’s «spoofable» or some odd).

The servers similarly have something they could set for the same effect (ClientKeepAliveInterval) but typically you don’t have control over those settings as much.

You can use «screen» util for that. Just connect to the server over SSH, start screen session by «screen» command execution, start your command there and disconnect (don’t exit screen session). When you think your command already done you can connect to the server and attach to your screen session where you can see the command execution result/progress (in case one should be).

See «man screen» for more details.

This should resolve the problem for ubuntu and linux mint add:

to /etc/ssh/ssh_config file

Instead of screen I’d recommend tmux, an (arguably) better competitor to screen

That command creates a session. Any time after that you want to connect:

there are two solutions

1. To update server and restart server sshd

echo «ClientAliveInterval 60» | sudo tee -a /etc/ssh/sshd_config

echo «ServerAliveInterval 60» >>

After having tried to change many of above parameters in sshd_config (ClientAliveInterval, ClientMaxCount,TCPKeepAlive. ) nothing had changed. I have spend hours and days to look for a solution on forums and blogs.

It appears that the problem of broken pipe which forbids to connect with ssh/sftp came from permissions settings on ChrootDirectory. the ChrootDirectory has to be owned by root/root with 755 permision lower permissions 765/766/775. won’t work but strongers do (eg 700) if you need to give a write permission to connected user, you can give it in sub-directories. if chroot is owned by sftpUser:sftpGroup, it won’t work neither.

hope it would help

If you’re still having problem after editing /etc/ssh/sshd_config or if

/.ssh/config simply does not exist on your machine then I highly recommend reinstalling ssh. This solution took about a minute to fig both «Broken pipe» errors and «closed by remote host» errors.

Источник

Что означает сообщение Broken pipe в сеансе SSH?

Иногда мой сеанс SSH отключается с сообщением Write failed: Broken pipe . Что это значит? И как я могу открыть сеанс?

Я знаю о screen , но это не тот ответ, который я ищу. Я думаю, что это вариант конфигурации sshd .

6 ответов

Возможно, ваш сервер закрывает слишком длинные простоя. Вы можете обновить либо ваш клиент ( ServerAliveInterval ), либо ваш сервер ( ClientAliveInterval )

Для обновления вашего сервера (и перезапустите sshd )

Или клиентская сторона:

Альтернативным решением было бы использовать mosh — мобильную оболочку . > . В отличие от ssh, он подключается через UDP и поддерживает роуминг. Вы можете начать свою сессию дома, приостановить работу своего ноутбука, взять его на работу /друзей /где бы вы ни располагали интернет, отказаться от своего ноутбука и продолжать работать так, как будто ничего не произошло. Это особенно полезно, если вы находитесь в паршивом интернет-соединении: он показывает мгновенную обратную связь, если ваши нажатия клавиш не доходят до сервера и постоянно пытается восстановить соединение.

Установка и настройка просты: теперь он включен во все текущие дистрибутивы Linux (плюс несколько не Linux) и координирует инициализацию и аутентификацию сеанса через предыдущее соединение ssh. Поэтому, если вы можете подключиться через ssh [email protected] , вы, скорее всего, сможете подключиться к mosh, просто позвонив mosh [email protected] , если пакеты mosh установленный на обоих концах.

Основная причина сбоев подключения заключается в том, что вам нужно добраться до сервера на UDP-порту (диапазон по умолчанию: 60000-61000) для работы mosh. Поэтому, если сервер находится за брандмауэром, вам в основном не повезло, если он не может пробить дыры в нем самостоятельно ( последствия для безопасности ).

Если вы хотите иметь более длительный период соединения, в клиенте добавьте:

ServerAliveCountMax по умолчанию это значение равно 3. Поэтому, когда ServerAliveInterval отправил 3 небольших пакета информации на ваш сервер, он автоматически выйдет из системы. Установка его на 1200 означает, что этот процесс должен произойти по крайней мере 1200 раз. Короче говоря, вы должны быть подключены не менее 30 * 1200 секунд (10 часов).

Обычно это означает, что ваше сетевое (TCP) соединение было сброшено. Например. ваш интернет-провайдер подключил вас или что-то вроде этого.

У меня была та же проблема, но это не так, как ожидалось. Если вы обнаружите, что в той же сети другой сервер пытается использовать тот же IP-адрес, вы столкнетесь с той же проблемой. Чтобы решить эту проблему, вам нужно проверить, есть ли другие серверы, которые используют один и тот же IP-адрес. Это можно сделать с помощью команды arp .

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

Вы заметите два набора MAC-адреса, используя тот же IP-адрес. Избегайте конфликтов, установив один на другой IP-адрес.

Другая причина для сообщения «Broken Pipe» заключается в том, что другой компьютер пытается использовать тот же IP-адрес, что и ваш хост.

Простой способ проверить, использует ли кто-нибудь другой IP-адрес:

1. Отключите хост
2. пинг одного и того же IP-адреса, чтобы узнать, использует ли другой компьютер этот IP-адрес

Чтобы узнать, какие компьютеры находятся в вашей сети, вы можете использовать этот Unix & Заголовок вопроса Linux: Как сделать найти, какие другие компьютеры подключены к локальной сети .

Источник

What does the Broken pipe message mean in an SSH session?

Sometimes my SSH session disconnects with a Write failed: Broken pipe message. What does it mean? And how can I keep my session open?

I know about screen , but that’s not the answer I’m looking for. I think this is a sshd config option.

9 Answers 9

It’s possible that your server closes connections that are idle for too long. You can update either your client ( ServerAliveInterval ) or your server ( ClientAliveInterval )

To update your server (and restart your sshd )

/.ssh/config on my Mac, do I have to create it there or it’s is somewhere else?

/.ssh ) first. So mkdir -p

If you want to have a longer connection period, in the client add:

ServerAliveCountMax by default this is set to 3. Therefore once the ServerAliveInterval has sent 3 small packs of info to your server it will then automatically log out. Setting it to 1200 means this process will have to occur at least 1200 times. In short you should be connected at least 30*1200 seconds (10 hours).

An alternative solution would be to use mosh — the mobile shell. In contrast to ssh it connects via UDP and supports roaming. You can start your session at home, suspend your laptop, take it to work / friends / wherever else you have internet, unsuspend your laptop and continue to work as if nothing has happened. It is especially useful if you are on a lousy internet connection: It shows instant feedback if your keystrokes don’t reach the server and continuously tries to reestablish the connection.

Installation and setup are simple: It is now included in all current Linux (plus a few non-Linux) distributions and it coordinates the session initialization and authentication via a prior ssh connection. So if you are able to connect via ssh user@server you are very likely to be able to connect with mosh just by calling mosh user@server , if the mosh packages are installed on both ends.

The main reason for connection failures is that you have to reach the server on a UDP port (default range: 60000-61000) for mosh to work. So if the server is behind a firewall you are mostly out of luck if can’t punch holes in it yourself (security implications).

Источник