Server Fault is a question and answer site for system and network administrators. 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

Our enterprise firewall is configured to disconnect ssh connections after 30 minutes of of inactivity. Sometimes, I need to perform an operation on a server that requires a sustained connection exceeding this period, but which my shell appears inactive (at least to the firewall).

It seems that opening a second ssh connection with continuous activity (say, running top) isn't enough to sustain the shell. I'd prefer not to set the process to the background and then foreground something more interactive, because any alerts or warnings might escape my attention. I could periodically, repeatedly hit the return key in the shell window every x-minutes, but that's undesirable.

Some programs, like sweep (from Sophos) have a cursor that rotates in the shell, sustaining the connection (that is, it cycles through \ | / – and so on). That works nicely.

Is there some trick, perhaps associated with bash, that could serve this purpose?

share|improve this question
up vote 3 down vote accepted

In your .ssh/config on your client, try adding something like this.

Host *
      ServerAliveInterval 60

man ssh_config

         Sets a timeout interval in seconds after which if no data has
         been received from the server, ssh(1) will send a message through
         the encrypted channel to request a response from the server.  The
         default is 0, indicating that these messages will not be sent to
         the server...

From putty, you would want to adjust the Connection\Seconds between keepalives to a non-zero value.

share|improve this answer
That's great -- I've been using OpenSSH, included on MOSX, and never thought to look in the client-side conf file (which I've customized in the past for things like GSSAPI). I can confirm, this is exactly what I was looking for. I wonder: does this parameter depend on the sshd on the other side supporting this keep-alive message? That is, does it need to also be OpenSSH (or compatible)? It seems to depend on v2 of ssh, but that's all I use anyway. – flumignan Apr 28 '11 at 0:19
@flumignan There are two types of KeepAlives: TCP and out-of-band. The option outlined in this answer is the out-of-band one, which is preferred when possible. Out-of-band KAs require server-side support, but all (recent) servers that I've seen support them. If your server doesn't support OOB KAs, TCP KAs are always an option, too; they're just not as flexible and significantly less pretty in terms of implementation (meaning they might break something if you're doing something odd, like using a funky terminal emulation), where the OOB KAs are "clean" in that respect. – BMDan Apr 28 '11 at 1:58
Experiencing the same issue; think it's related to a specific WiFi network as on another network there's no problems. Will try this method and see if it works for a flaky wifi causing the disconnects. – M1ke Jan 7 '15 at 12:04
Seems to be working so +1! – M1ke Jan 7 '15 at 13:29

If running within a screen session - you could add "system load" counters to the bottom of the screen (or system date/time - adding something like caption always "%d.%m.%y %0c%{=b kW}" to your .screenrc could do that), which will non-regularly generate some minor output (redrawing load numbers or date/time).

This is how it looks - lower left corner, system load

This is how it looks - lower left corner, system load

An even less straight :) solution (with keepalives being the straightest) would be to have some shell script running in background and generating some output to stderr every 30-60 seconds... E.g. while true; do echo "ding" > /dev/stderr; sleep 30; done &.

share|improve this answer
+1 for screen... – Marco Ramos Apr 27 '11 at 23:42
The (very) old-school way to do this was something like: ( while [ true ]; do /bin/echo -ne '\000'; sleep 60; done ) &. KeepAlives are the right solution, but this sort of option is always an amusing side discussion, if nothing else. :) – BMDan Apr 28 '11 at 1:52

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.