2

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?

Improve this question

2 Answers 2

Reset to default
3

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

Host *
      ServerAliveInterval 60

man ssh_config

 ServerAliveInterval
         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.

Improve this answer
4
  • 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, 2011 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, 2011 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, 2015 at 12:04
  • Seems to be working so +1!
    – M1ke
    Jan 7, 2015 at 13:29
1

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 &.

Improve this answer
1
  • 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, 2011 at 1:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .