I'm trying to use an SSH tunnel from home trough a computer in the university so I can access some articles.

Both machines are running Ubuntu 11.04. The university's machine runs openssh-server.

At home I followed these instructions:

  1. open an ssh session:

    ssh -D 9999 -C user@my_addr.com 
  2. Then I configured Firefox to user SOCKS5 connection on port 9999 of localhost.

This works for some time. Then, it suddenly hangs the connection and the terminal just freezes.

What am I missing here?

  • 2
    Is the SSH connection still active at the time this occurs? Maybe a firewall drops "inactive" connections?
    – Bram
    May 11, 2012 at 12:48
  • Yeap. I have thought about that. So I created a little script to just ping google every 10 seconds, to "keep the connection alive", but it didn't work.
    – lcguida
    May 11, 2012 at 13:08
  • 1
    Does a straight ssh session behave the same way, i.e. if you connect to the remote machine and then use it for a bit, does it eventually hang? That'll rule in or out the tunnelling element. May 11, 2012 at 13:31
  • Maybe running ssh with -v and see what gets printed out when the connection dies.
    – ckhan
    May 13, 2012 at 1:42
  • I have checked that now. Straight ssh session does'nt seems to hang. I also tried autossh -D <port> -c <user@host>. When just using the terminal for commands, went fine. Started the browser, terminal froze.
    – lcguida
    May 30, 2012 at 12:15

4 Answers 4


You can try setting the ClientAliveInterval and ClientAliveCountMax variables in your sshd config file to values that suit you.

From the manual:


Sets a timeout interval in seconds after which if no data has been received
from the client, secshd will send a message through the encrypted channel 
to request a response from the client.
The default is 0, indicating that these messages will not be sent to the 
client. This option applies to protocol version 2 only.
  • 1
    I've tried that. No success.
    – lcguida
    Jul 17, 2012 at 20:40

Try autossh. It detects hung connections and reconnects automatically. I used it in a similar situation in the past and it worked well for me.


  1. I used to run it in screen, which has two benefits: run (sort of) in the background, and possible to return to the session later to check its status and debug if necessary, like this:

    screen -d -m -S my-autossh-tunnel autossh your_autossh_args

    This will start screen in the background. If you want to check on the autossh process, you can reconnect to this screen session with screen -R my-autossh-tunnel

  2. I used empty passphrase for convenience, but for added security I used the following options in the authorized_keys at the remote end:


    This way the tunnel can be established with the key, and the shell cannot be misused for anything else.

  • 1
    autossh works, but not on the background. I also had to user public key to avoid password, otherwise atussh would keep propmting me for it.
    – lcguida
    May 17, 2012 at 12:43
  • I run autossh within a screen session. It's better then background, as I have a dedicated "window" for it that I can detach from and re-attach later to check on the status.
    – janos
    Feb 12, 2013 at 16:01

I also suggest use autossh with while script for example:

I have this in crontab:

@reboot while true; do sleep 10; autossh -i /some/location_not_default.pem -D 9999 -L 1028:localhost:3128; done

while will always trying to connect, and establish the connection, create a socks port, and forwording squid port. This proven to be very stable for me.

  • Looks you have a spelling mistake. It should be while true
    – Robin
    May 16, 2012 at 19:45
  • I'll try this one. Put the fedback later.
    – lcguida
    Jul 17, 2012 at 20:40
  • works for me for a long time. the process stayed 300 days +
    – c2h2
    Jul 18, 2012 at 12:10

I had the same problem with using VNC over SSH tunnel. The freezes occured frequently, both with putty (windows) and openssh (linux).

With putty I copied the connection profile and changed a few options just to see what happened and no more freezes! The changes in putty are:

Connection: UNCHECK "disable Nagle's algorithm" (I left "enable TCP keepalives" checked and "seconds between keepalives" at 30) SELECT "internet protocol version" IPv4 (instead of "auto")

Connection - SSH: CHECK "Enable compression"

I am not sure what option did the trick, but I am a happy camper now. I cant get it to freeze, but when I switched back to the old profile to check, it froze within a few seconds.

The freezes occured mostly when sending large updates over VNC, like scrolling a window. Perhaps the disabled Nagle algorithm flooded the server with too many small packets or perhaps because ipv6 was disabled on the remote VNC server but not on the other hosts. It would require some more testing with the individual options to figure that out.

You must log in to answer this question.

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