Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

What can I do to configure SSH on both client and servers to prevent Write Failed: broken pipe errors? It often occurs if you sleep your client computer and resume later.

share|improve this question
2  
Nothing really. The session was interrupted, and the security of the session was compromised. If you don't put the comp to sleep you can set a keep alive time for the client to shoot a keep alive heart beat to the server, but if the system's going to sleep then there is nothing that can be done. –  darkdragn Apr 28 '12 at 23:44
    
SHH sessions rotate encryption keys over time, to prevent long timescale brute force attacks. Sleep / resume will break this security and the connection. –  david6 Apr 29 '12 at 1:58
    
In this case I'm looking for something that would allow me to re-initiate a broken ssh connection (based probably on the exit code) and restore using screen? –  sorin Apr 30 '12 at 7:11
add comment

7 Answers

I have tried this in /etc/ssh/ssh_config for Linux and ~/.ssh/config for Mac:

Host *
ClientAliveInterval 120
ServerAliveInterval 120

This is how often, in seconds, it should send a keepalive message to the server. If that doesn't work then train a monkey to press enter every two minutes while you work.

share|improve this answer
1  
Yeah I do similar and it works quite well for most things. –  Oli Aug 25 '12 at 0:25
1  
I'm not on a Mac, but Ubuntu 12.04 and the file for this operating system also seems to be ~/.ssh/config. –  broiyan Dec 14 '12 at 13:26
3  
OS X 10.8.4 gives an error Bad configuration option: ClientAliveInterval –  ohho Jul 15 '13 at 4:46
3  
I get that same Bad configuration option error on OSX 10.8.4. –  Rosarch Jul 18 '13 at 19:57
2  
Generally, you put these two commands into different parts of the system. Only ServerAliveInterval on the OSX client side... and only ClientAliveInterval on the sshd config file... –  ftrotter Oct 23 '13 at 22:56
show 5 more comments

SSH sessions may break due to numerous and possibly unavoidable reasons.

A useful utility which can be used to mitigate problems caused by this is called screen. Screen is a powerful utility that allows you to control multiple terminals which will stay alive independently of the ssh session. For example, if you run screen in an ssh session you will see a new terminal open and you can use that to run jobs. Lets say your ssh session dies in the process. Running screen -d then screen -r will reopen the last session and you will be able to continue from there. Make sure you read some of the documentation before using it.

share|improve this answer
    
This is probably the best answer, I'm not sure why it's not voted up higher. The other "fixes" are helpful in the special case where you would actually care about maintaining an SSH connection, but in most use cases I imagine the real concern is that the intended processes continue to run, regardless of any client/server connection issues whatsoever. –  Paul McMurdie Jun 3 '13 at 17:33
add comment

I'm remotely upgrading an Ubuntu server from lucid to precise and lost the ssh connection in the middle of the upgrade with the message "Write failed. Brocken pipe". ClientAliveInterval and ServerAliveInterval did nothing. The solution is to turn on TCPKeepAlive options in client ssh:

TCPKeepAlive yes

in

/etc/ssh/ssh_config
share|improve this answer
add comment

I have a script on the remote server that never seems to fails, regardless of the SSH configuration client or server.

#!/bin/bash
while true; do date; sleep 10; done;

Save it to some dummy.sh file and quickly run it before you minimize the window or move away from it. It will keep printing the current time stamp on the server and keeps your connection alive as long as the connection is not dropped by any other reason. When you get back to that terminal, just hit CTRL+C and keep working.

share|improve this answer
2  
or simply leave top running –  Eben Geer Dec 19 '13 at 22:43
add comment

Client configuration

Try creating the file:

~/.ssh/config

Add the contents:

Host *
  ServerAliveInterval 30
  ServerAliveCountMax 5

Now ssh to your server and see if your problem is fixed. ClientAliveInterval option is only useful when configuring the ssh server (aka sshd), it does not change a thing on the ssh client side, so don't use it in the above configuration file.

This will send a hello-are-you-there signal to the server if no packets have been received in the preceding 30 seconds (as specified above). However, if the number of consecutive hello-are-you-there signals reach ServerAliveCountMax then ssh will disconnect from the server. This value is defaulting to 3 (so 3*30 = 90 seconds without server activity), increase it if it suits your needs. There are alot more config options to the .ssh/config file and you could read:

Using an SSH Config File

For more information on other options. You may not want to apply this to every server you connect to which this example will. Or restrain it to only a particular server by replacing the line Host * with Host <IP> (replace by an IP address, see ssh_config man page).

Server configuration

Similarly you can tell the server to be gentle with your clients. The configuration file is /etc/ssh/sshd_config.

ClientAliveInterval 20
ClientAliveMaxCount 5

You can either deactivate it by setting ClientAliveInterval to 0 or tweak ClientAliveInterval and ClientAliveMaxCount to set a maximum ssh client inactivity without responding to the probes. One advantage of this settings over TCPKeepAlive is that the signals are sent through the encrypted channels, so it is less likely to be spoofable.

share|improve this answer
    
It doesn't work. I am facing the same error again. –  user997704 Oct 6 '13 at 4:59
    
Try it straight from the command line and go lower: ssh -o ServerAliveInterval=5 user@host –  Matt Oct 6 '13 at 10:46
    
Tried that too..doesn't work. I really don't know what is going on with my system –  user997704 Nov 15 '13 at 8:39
add comment

I had the same issue after migrating a VM. Turns out the VM was still runing in old Dom0! we had the same host running in 2 different places!

Once the old one was shutdown...viola!

share|improve this answer
add comment

If you are using your client ubuntu on a VM then just change the network adapter of your VM to NAT. This solved the problem for me..

share|improve this answer
    
No VM and all. It is a normal Ubuntu machine. –  user997704 Nov 23 '13 at 9:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.