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 '12 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 '12 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. – EightBitTony May 11 '12 at 13:31
  • Maybe running ssh with -v and see what gets printed out when the connection dies. – ckhan May 13 '12 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 '12 at 12:15

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.

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

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.
| improve this answer | |
  • 1
    I've tried that. No success. – lcguida Jul 17 '12 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.

| improve this answer | |
  • 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 '12 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 '13 at 16:01

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.