Image of the glider from the Game of Life by John Conway
Skip to content

Keeping Your SSH Connection Alive

Being an instructor for Guru Labs, I'm in training centers all over the nation. As such, I never know what hardware I'll be facing, or for that matter, their network setup. This can be problematic, as setting up for class could present troubleshooting on my end before students arrive and class starts.

One of the issues that has plagued me, but I haven't bothered to do anything about it until this morning, is networks dropping my TCP connections if there is no activity after a given interval. Currently, I'm in Mountain View, California teaching a Linux course, and the training center network is one such network with dropping inactive TCP connections after 60 seconds. Annoyed (being a heavy SSH user), I began digging in the SSH man page on my machine, and found a way to keep my connection alive.

There are two options for addressing my need: TCPKeepAlive and ServerAliveInterval. Each of those are explained here:

  • TCPKeepAlive: This uses the KEEPALIVE option of the TCP/IP protocol to keep a connection alive after a specified interval of inactivity. On most systems, this means 2 hours. So, with the TCPKeepAlive option passed to SSH, the SSH client will send an encrypted packet to the SSH server, keeping your TCP connection up and running.

    ssh -o TCPKeepAlive=yes

  • ServerAliveInterval: This sets a timeout interval in seconds, which is specified by you, from which if no packets are sent from the SSH client to the SSH server, SSH will send an encrypted request to the server for a TCP response. To make that request every 30 seconds:

    ssh -o ServerAliveInterval=30

If ServerAliveInterval is used in the SSH command, then TCPKeepAlive is not needed, and should be turned off.

Now, in the training centers I visit, giving this option will ensure that my SSH connection stays connected, so I can stay on top of my IRC and MUC. 🙂

{ 13 } Comments

  1. Bjørn Grønbæk | April 16, 2008 at 11:45 am | Permalink

    Thanks man. I'm having the exact same problem here at University of Southern Denmark. Stupid network...

    It really screws up your system if you mount a remote folder with sshfs, and the connection is terminated by inactivity. It would be nice if sshfs had some option just like those above. But your advice is a great help anyway.

  2. Steve | April 16, 2008 at 1:37 pm | Permalink


  3. Aaron | April 16, 2008 at 2:45 pm | Permalink

    @Bjørn Grønbæk- It does. Add either of those options to your ~/.ssh/config file. The sshfs utility reads that file, and adds the options to the connection, as sshfs just just an ssh directory mounted to a local dir on your filesystem.

  4. Kurt | April 17, 2008 at 5:16 am | Permalink

    What about using autossh?

  5. Hans | April 17, 2008 at 9:41 am | Permalink

    autossh has its place, but its job is to automate reconnecting in the event of a disconnect, not keeping a connection alive.

  6. GNUWIX | March 23, 2009 at 11:19 pm | Permalink

    So, with the TCPKeepAlive option passed to SSH, the SSH client will send an encrypted packet to the SSH server, keeping your TCP connection up and running.

    This is inaccurate.. This is a TCP option and will not send "an encrypted packet"

    Otherwise pretty good post thank you

  7. dr. x | July 17, 2009 at 8:12 pm | Permalink

    hmmm... i *think* (am no expert) you really would want to turn OFF TcpKeepAlive, not turn it on.

    If you have it ON the client/server will notice when the connection is unresponsive and... as seems to be implied by the man page, close the socket. Which is what some people find annoying... as expressed in the man page entry below.

    from the man page for ssh_config:

    Specifies whether the system should send TCP keepalive messages
    to the other side. If they are sent, death of the connection or
    crash of one of the machines will be properly noticed. This
    option only uses TCP keepalives (as opposed to using ssh level
    keepalives), so takes a long time to notice when the connection
    dies. As such, you probably want the ServerAliveInterval option
    as well. However, this means that connections will die if the
    route is down temporarily, and some people find it annoying.

    The default is “yes” (to send TCP keepalive messages), and the
    client will notice if the network goes down or the remote host
    dies. This is important in scripts, and many users want it too.

    To disable TCP keepalive messages, the value should be set to

  8. Tim Smith | February 7, 2011 at 3:25 am | Permalink

    Dr X,

    The point of this work around is to get around firewalls detecting the SSH sessions as idle, and dropping them out of their state tables. Then when the client tries to send it's next packet, the firewall will drop it, as it will see it out of state.

    You can disable this behaviour on firewalls, but that is there job 🙂 So better off to adjust on the clients / applications



  9. Jordan | July 26, 2011 at 5:32 pm | Permalink

    Thank you!! =) I've been using ssh for years, but have recently started delving into its less common features. This is a gem... =)

  10. Andy P | July 2, 2012 at 1:35 pm | Permalink

    Thanks for this, very helpful.

  11. Seb | January 9, 2013 at 5:46 am | Permalink

    damn, the ServerAliveInterval is a killer feature, you made my day, thanx a lot

  12. Shawn | November 4, 2013 at 5:11 pm | Permalink

    Any considerations about using BOTH TCPKeepAlive and ServerAliveInterval?

    as far as TCPKeepAlive ... who really cares if they spoof a keepalive?? unless they can also spoof a reset?

  13. a | April 22, 2014 at 12:35 pm | Permalink


{ 2 } Trackbacks

  1. [...] Encore une fois, je ne réinventerai pas la roue puisqu’une recherche sur Google vous conduira sur ce blog : Aaron Toponce : Keeping Your SSH Connection Alive. [...]

  2. [...] the TCP Keep Alive method, or the ServerAliveInterval method. Both of which are outlined briefly here.  I prefer ServerAliveInterval as it’s easier for me to remember. Add the following two [...]

Post a Comment

Your email is never published nor shared.