Wow this is so cool. Sometimes, OpenVPN traffic is blocked using deep packet inspection and the likes. I use shadowsocks to access internet there but it requires additional server setup.
SSH Tunneling works with zero config so I use it as well, and rsp solves one of my major gripes with ssh tunnelling.
Hmm, cool project. Making it work over MPTCP [1] could also make it a kind of replacement for shadowsocks [2] for the purpose of converting plain TCP to Multipath TCP, as it is used in OpenMPTCPRouter [3]. Shadowsocks is used for MPTCP proxying instead of plain socks exactly b/c it uses separate connections for separate flows.
The multiplexing you can disable on the server-side is a different multiplexing, but also another useful ssh feature.
If you have a workload that involves sort of firing off many commands over ssh one after the other (i.e next command is based on the output of the previous), then you can make them all grab a prenegotiated ssh connection to speed it up.
in my ssh configs to take advantage of this in my Makefiles which need to ssh across for various reasons. Ssh commands to a "central location" are great for initializing env vars with AWS keys, instead of encoding them in shell scripts - easiest way to prove your identity is to prove you have your private key.
No, it's the SSH client who responsible which SOCKS request will be wrapped in which SSH connection. Stock implementation opens forwarded connections inside virtual channel of single SSH session.
Besides that you have to keep pool of steady established SSH sessions in order to start new connection forwarding inside separate SSH session as soon as incoming SOCKS requests coming.
Plain SSH client is neither able to maintain multiple SSH carrier sessions nor keep reserve pool of steady underlying connections.
So I've implemented own client which decouples connections from each other: https://github.com/Snawoot/rsp#performance
Basicly, you get working proxy with speed almost as native connection as soon as you have SSH access somewhere.