Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

When I'm ssh'ed into one of our office servers (which run Fedora 10) from home, my session times out after a fairly short period of activity (5 minutes or so). I've tried using TcpKeepAlive on the client side, to no effect.

The thing I don't understand is that if I'm in the office on the company LAN, I can leave a session inactive all day without it timing out, so the behaviour seems to be dependent on my location.

Any ideas why this is happening and how to prevent timeouts when I'm not on the LAN ? I'm using the Terminal client on Mac OSX if that helps.

UPDATE - Dave Drager's suggestion of using the ServerAliveInterval set to non-zero with TcpKeepAlive=no worked for me. Regarding some of the other answers, the ClientAlive... settings aren't accepted by the Mac OSX SSH client.

share|improve this question
up vote 6 down vote accepted

There is a good writeup on this problem here.

They recommend:

ssh -o TCPKeepAlive=yes


ssh -o TCPKeepAlive=no -o ServerAliveInterval=15

However, I do have an issue at my work site where I get disconnected from sessions, where at home they are fine. I believe my firewall (SonicWall) may be flucking with TCPKeepAlive, maybe because of NAT.

My SSH client, SecureCRT, fortunately has an option for a "NO-OP" protocol, which I believe basically sends a command that doesn't do anything to the server. By manually enabling this I am able to remain connected. Not sure what the MacOSX terminal client has that is similar to that. There is a writeup on how to implement "NO-OP" on command line.

Finally, you may wish to use Wireshark or other sniffer to watch your actual TCP connection to find out what is going on with it. That would be the final way to see why it is still disconnecting occasionally.

share|improve this answer
Thanks, Dave - the ServerAliveInterval option worked great. – gareth_bowles Jun 17 '09 at 23:40
@Dave I had heard that some server admins frown on this practice as it can be either (a) security risk, or (b) unwarranted server load. Are either of these concerns valid, IYHO? – Jonathan Day Aug 22 '11 at 5:32
This is a setting on the client endpoint, so although if you are in a hostile environment this might add to the ability for someone to spoof you, it is very highly unlikely to make an impact on the security of the connection. I can't really see this causing extra load, either. – Dave Drager Aug 23 '11 at 15:53
@Dave:I entered this command but get the following, usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec] [-D [bind_address:]port] [-e escape_char] [-F configfile] [-I pkcs11] [-i identity_file] [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port] [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]] [user@]hostname [command] – user1050619 May 10 '14 at 20:21
This fix worked for PuTTY as well. The only option I had to set was in Connection -> Seconds between Keepalive: 15. SSH session has been alive and well for over 8 hours (Comcast), while it would usually disconnect in <30 minutes. – Dan Dascalescu Jul 2 '15 at 20:34

This is probably because when your are connecting from home you pass through a firewall that close TCP session after a small amount of time. But TcpKeepAlive should avoid this. Did you enabled TcpKeepAlive on client side or on server side ?

share|improve this answer
I did the TcpKeepAlive on the client side (in my ~/.ssh/config) - I thought this would address local firewall issues, but it still times out. – gareth_bowles Jun 17 '09 at 15:58
By default it's "on" on the server side, but check the sshd_config to see if it has not been disabled. – radius Jun 17 '09 at 16:08
Some firewalls disconnect a TCP connection after a certain amount of time EVEN if they aren't idle. – TomOnTime Jun 17 '09 at 17:52
Some firewalls disconnect a TCP connection after a certain amount of time EVEN if they aren't idle. The way to detect this is to see if you get disconnected consistently. – TomOnTime Jun 17 '09 at 17:53
Here are the settings I used to fix: TCPKeepAlive no, ClientAliveInterval 300, ClientAliveCountMax 3 – Matt Simmons Jun 17 '09 at 18:12

I get this all the time on my Comcast connection. The problem is that your SSH client's keep-alive interval is too long for the timeout configured in your network path. If you're on Linux, you can modify the ServerAliveInterval and ServerAliveCounter values to be lower than their defaults. This value is set in seconds. The system-wide config file is found (generally) in /etc/ssh/ssh_config. Setting those two AND TcpKeepAlive should help keep your connection going.

share|improve this answer

Like radius says, some state-full firewalls do 'forget' a connection after certain (usually configurable) time and will not allow further communication for the connection; they expect the connection to start with a TCP SYN (i refer to your SSH communication here).

There is another possibility. The network path between your home and office may have losses (of the packet kind). When you try to type on the SSH client, if your link has stalled for a while, the client might give up and fail.

Keepalive configuration on the client will handle the first case here but cannot help in the second case. The firewall would usually be at your office perimeter and therefore might be configurable. That would also help on the first point.

To check if you are having intermittent link losses you could keep a 'ping' active in the background from your client machine.

share|improve this answer

You can also add the settings suggested by others as defaults in your ~/.ssh/config file, so you don't have to pass them to ssh every time you initiate a connection:

nano ~/.ssh/config and add:

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.