The question Using an already established SSH channel has an answer that intrigued me. It suggests that I can reuse an existing SSH connection. However, after further reading, I see that this solution may not work in my case (multiple tunnels at the same time).

I'm using OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012 (on Kubuntu 12.04).

Here is what I'm currently doing in a bash script:

echo "establishing SSH tunnel for SFTP && opening Dolpin with SFTP connection to remote computer..."
ssh -i "$ID_RSA" "$MIDDLEMAN_USER@$MIDDLEMAN_SERVER" -fL $PORT_NUMBER:localhost:$PORT_NUMBER sleep 20; dolphin sftp://HostSftp:$PORT_NUMBER &

echo "establishing SSH tunnel for VNC && connecting to VNC server for remote desktop support..."
sudo ssh -fL 5901:localhost:$VNC_PORT_NUMBER -i "$ID_RSA" "$MIDDLEMAN_USER@$MIDDLEMAN_SERVER" sleep 20; vncviewer localhost:5901

My concerns (why I think this might not work for me) include things like this:

A negative to this is that some uses of ssh may fail to work with your multiplexed connection. Most notably commands which use tunneling like git, svn or rsync, or forwarding a port. Source

and this:

If you use LocalForward or RemoteForward in your configuration file, you might run into a subtle problem. ... SSH1 (but not OpenSSH) provides a solution. Source

I'm looking for clarification as well as instruction:

  1. Can I establish the two tunnels above with one master connection?
  2. Will this be as reliable as establishing separate connections?
  3. If yes to both the above, how do I do it?


1 Answer 1


Using a master connection doesn't change the way you invoke ssh, except for the options related to connection sharing (-S, -M, -o ControlXXX). All a master connection changes is that when a master connection is already established, new slave connections go through that rather than authenticating again. This saves the need to provide a password or key, and can noticeably speed up the establishment of the new connection.

Multiplexing doesn't make any difference to applications. It makes a difference to firewalls: there's a single connection instead of many.

I don't know why Symkat claims that “ssh may fail to work with your multiplexed connection. Most notably commands which use tunneling like git, svn or rsync, or forwarding a port.”. If it worked without multiplexing, it'll also work with multiplexing, because the applications can't tell the difference.

The Definitive Guide to SSH isn't refering to connection multiplexing but to “us[ing] LocalForward or RemoteForward in your configuration file”. (That book dates from before connection multiplexing existed.) It's saying that you can establish a tunnel listening on a given port only once. This is about forwarding, not about multiplexing.

To start using multiplexing, add the following lines to your ~/.ssh/config:

ControlMaster auto
ControlPath ~/.ssh/%l_%h_%p_%r.multiplex

That's all. If you want to establish a connection to a host and keep it around until explicitly killed, run ssh -N destination &. When you no longer want that master connection, kill the client. You'll still need to set up your tunnels exactly as before.

If you're using a host as a relay for many things, you may want to set up a SOCKS proxy. Run ssh -D 1234 destination and tell your SOCKS-aware applications to use the SOCKS proxy at localhost:1234. Of course this only works with applications that understand SOCKS; you can use tsocks to the network connections of most non-SOCKS-aware applications to go through the SOCKS proxy (tsocks works by redirecting library calls to wrapper functions).

  • 1
    Great explanation. The implementation seems too easy. :-)
    – MountainX
    Commented Jul 22, 2013 at 2:17

You must log in to answer this question.

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