Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I found this question, but I'm sorry I don't quite understand the settings on the two variables ServerAliveInterval and ClientAliveInterval mentioned in the accepted response. If my local server is timing out, should I set this value to zero? Will it then never time out? Should I instead set it to 300 seconds or something?

My question is simply, some of my connections time out when I suspend & then unsuspend my laptop with the response Write failed: Broken pipe and some don't. How can I correctly configure a local sshd so that they don't fail with a broken pipe?

share|improve this question
up vote 94 down vote accepted

ServerAliveInterval: number of seconds that the client will wait before sending a null packet to the server (to keep the connection alive).

ClientAliveInterval: number of seconds that the server will wait before sending a null packet to the client (to keep the connection alive).

Setting a value of 0 (the default) will disable these features so your connection could drop if it is idle for too long.

ServerAliveInterval seems to be the most common strategy to keep a connection alive. To prevent the broken pipe problem, here is the ssh config I use in my .ssh/config file:

Host myhostshortcut
     HostName myhost.com
     User barthelemy
     ServerAliveInterval 60

ClientAliveCountMax on the server side might also help. This is the limit of how long a client are allowed to stay unresponsive before being disconnected. The default value is 3, as in three ClientAliveInterval.

share|improve this answer
Ok, so I would interpret zero seconds to imply "don't keep alive" which is why it doesn't poll the client/server? – M. Tibbits Oct 12 '10 at 16:33
yup 0 = don't send a null packet. Another different would be that ServerAliveInterval is set in the client config whereas ClientAliveInternal is set in the server config. – Barthelemy Oct 12 '10 at 16:37
Thaaaaaanks!!!! (needed more than 15 characters) – M. Tibbits Oct 12 '10 at 17:06
This seems like good advice to prevent idleness causing timeouts, but I don't understand how it relates to the OP question of preventing broken pipes when the client suspends. When asleep, the client would not be able to send a null packet, so surely this setting is moot? – Sparhawk Oct 6 '13 at 2:12
The ServerAlive portion is, certainly. ClientAliveInterval/ClientAliveCountMax is what would help here. – javawizard Sep 29 '14 at 19:53

Since you can't guarantee that an SSH connection (being TCP) will remain alive once one end stops sending ACKs to received packets, I personally use http://www.harding.motd.ca/autossh/ to restart all my SSH connections almost as soon as I unsuspend.

Since GNU Screen will be in use on the server side, re-attaching gets me to where I was before.

You can have it listening on extra ports so that it continually checks the connections are still alive, but personally I find it works well enough with that disabled and just relying on SSH's own ServerAliveInterval / ServerAliveCountMax.

Another option is http://mosh.mit.edu/ which uses UDP and recovers seamlessly from long term lack of connectivity.

share|improve this answer

The Answer from Barthelemy is cool but doesn't really get to the root of the problem. You suspend your machine and want the SSH session to be still alive when you boot up your computer.

There is no such configuration for ssh that will keep the connection alive like that. SSH uses TCP, for a start you need the three way handshake and then keep alive after some idle time. When you shutdown/hibernate all your TCP connections are closed with FIN. No way to overcome that.

For a dirty workaround you can use VPS or another online box with screen to keep the connection. My advice don't do that for security reasons.

share|improve this answer
This is in fact the one and only answer to the question. – Calimo Oct 6 '14 at 15:21
This is in fact a terrible security solution, never do that. – jahrichie May 28 '15 at 18:16

You could also run commands with nohup if you want them to run regardless of your SSH connection.


$ nohup tar -xzf some_huge.tar.gz &

The & is, I think, not necessary, but it is convenient since it makes the process run in the background so you can do other stuff.

I always use nohup for any process that takes awhile, so that I don't have to start over if I lose the connection for whatever reason - power outage (at my remote location, not at the host obviously), network outage, whatever.

share|improve this answer

Put your long running session inside screen See screen -h for details

That way you can reconnect to the machine using ssh and reattach to the screen session

share|improve this answer

Your Answer


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.