Edit: xiringuito uses the SSH tun/tap feature, which does TCP-over-TCP tunneling (which performs badly[1]). sshuttle instead multiplexes the TCP streams over a single connection by capturing them and opening a new TCP session at the remote end. This means it does not need root permissions on the remote side, since it does not need any raw sockets or even create tap devices.
The SOCKS proxy and the port forwards (-L, -R etc) work similarly, it's just the tunnel feature which should be avoided since it forwards whole packets.
Does sshuttle still cause occasional kernel panics on MacOS? (This is a real question, not a troll - I haven't used sshuttle for several years and it was a known issue among my colleagues at the time)
This creates an Auto closing SSH Tunnel (Tunnel will close if Chrome exits) to a remote ssh server and redirect to localhost on port 7070 and launch Chrome Portable using local port 7070 as socks 5 proxy
The following command is for cygwin on Windows.Can be customised for Mac OS or Linux
I use ssh -D along with https://github.com/darkk/redsocks to get system wide transparent tunneling working. Using iptables you can do per user, process etc. Works with every application :)
While most systems have a system-level dialog to enter in SOCKS proxy information, it's still typically up to the application to obey that setting, and most outside of web browsers don't.
There are some applications out there (e.g., tsocks) that hook the relevant system calls, but I find them quite annoying to use. (You need still something to trigger them, to say "this connection should be proxied") I've also had issues with proxy applications whose system call hooks fail to implement the system call. (E.g., one would return from connect immediately with success, every time, prior to the connection actually being established. When the connection failed to establish, the send/recv call would fail. The application would immediately loop back to re-establishing the connection. This caused an infinite loop, since the first DNS entry it was encountering was never going to work; it would have skipped it when the connect() call failed, but then, the connect call wasn't failing.)
Another approach is to run a localhost-interface only web proxy on the remote system and ssh -L 127.0.0.1:3128:127.0.0.1:3128 remotehost ... which replicates the remote proxy port on your local system.
Why on Earth would you run OpenVPN through ssh? That makes zero sense. It's like running ssh through ssh.
OpenVPN is pretty much the ultimate VPN that can do anything and handle any situation. It is indistinguishable from regular web SSL traffic and can run on any port via TCP or UDP. It can even run in routed (TUN) or promiscuous (TAP) mode!
Once you've got OpenVPN setup there's no need to tunnel with ssh since OpenVPN is your tunnel.
I used to run an OpenVPN ISP named VPNOut many years ago. I had CTOs from large organizations begging me to tell them all the IPs I used so they could block it because apparently employees were using my service to access things that were normally blocked inside their corporate networks. Even to this day that problem exists: If you configure iptables to forward all ports to an OpenVPN daemon on both TCP and UDP you can get around basically any form of blocking that isn't IP-based. You can even do some tricks to make it look like regular web traffic for the initial SSL preamble to get around "intelligent" firewalls!
I like OpenVPN too. However, there are times when one size doesn't fit all. For example, opening another service to the public is not always a good idea. GFW is programmed to profile and periodically kill OpenVPN traffic flows. OpenVPN under many configurations is MITMable, SSH much less so. The list goes on.
OpenSSH and OpenVPN have nearly identical attack vectors with regard to MITM. In a default configuration, both require an upfront exchange of public keys (SSH at time of first-connection; OpenVPN at time of first-configuration).
In fact, because OpenVPN requires the client to obtain the server's certificate ahead of time out of band, and SSH instead relies on the end user typing "yes" after manually comparing a fingerprint, it could be argued OpenVPN is less susceptible to a MITM attack.
edit:
Additionally, from past experiences linking up cn-north-1 with us-east-1, individual SSH tunnels fail constantly. individual VPN sessions fail constantly. The only way we were able to make life livable between the two was by way of BGP across a combination of ipsec and openvpn tunnels. (different tunnels, mind you; not layered)
They are not identical in attack vectors, and OpenVPN has many more capabilities to resist MITM and other attacks, and it resists network failure much more.
OpenSSH uses the SSH protocol and username/password and public keys for auth.
OpenVPN auth uses TLS key exchange, pre-shared keys, and username/password, and uses IPSec's ESP protocol for transport, with custom work to handle multiplexing connections. It can verify HMAC on all packets. It tunnels layer 2 or 3. It won't swap sensitive memory and can utilize SELinux. Since OpenVPN can use static keys and a UDP transport, it can resist network partition much better than OpenSSH.
Of course IPSec is much better than either of them. If you have to do all your tunneling in userland, OpenVPN is a more secure method, but if you don't have tun/tap device access, OpenSSH will get you by with port forwarding (which is what its SOCKS tunnel is, if you don't use its tun/tap device or pppd).
OpenSSH and OpenVPN have nearly identical attack vectors with regard to MITM.
Perhaps in theory, but in practice I would argue otherwise. Why?
Most SSH configurations require key verification and are rarely modified otherwise.
By contrast many OpenVPN configurations, statistically, have MITMable keys, and as they tend to be written from scratch the likelihood of these configurations in the wild is much higher.
With regards to SSH tunnel longevity, try specifying the ServerAliveInterval and ServerAliveCountMax options.
https://github.com/apenwarr/sshuttle
Edit: xiringuito uses the SSH tun/tap feature, which does TCP-over-TCP tunneling (which performs badly[1]). sshuttle instead multiplexes the TCP streams over a single connection by capturing them and opening a new TCP session at the remote end. This means it does not need root permissions on the remote side, since it does not need any raw sockets or even create tap devices.
The SOCKS proxy and the port forwards (-L, -R etc) work similarly, it's just the tunnel feature which should be avoided since it forwards whole packets.
[1]: http://sites.inka.de/bigred/devel/tcp-tcp.html