Multiple SSH tunnels (local and remote forwarding) over one master OpenSSH connection? Good idea?

Question

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?

Thanks

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