Sshuttle eng
Introduction
Do you ever wanted to use SSH as a VPN? There is little piece of useful utility called sshuttle is available to completely turn your SSH connection as VPN. sshuttle is a transparent proxy server that works as a poor man’s VPN over ssh. You don’t need any admin account on your remote system. It supports DNS tunneling and works with Linux and MacOS platforms.
The program is suitable for the cases when:[1]:
- Your client machine (or router) is Linux, FreeBSD, or MacOS.
- You have access to a remote network via ssh.
- You don’t necessarily have admin access on the remote network.
- You don’t want to create an ssh port forward for every single host/port on the remote network.
- You hate openssh’s port forwarding because it’s randomly slow and/or stupid.
How it works [2]
sshuttle is not exactly a VPN, and not exactly port forwarding. It’s kind of both, and kind of neither.
It’s like a VPN, since it can forward every port on an entire network, not just ports you specify. Conveniently, it lets you use the “real” IP addresses of each host rather than faking port numbers on localhost.
On the other hand, the way it works is more like ssh port forwarding than a VPN. Normally, a VPN forwards your data one packet at a time, and doesn’t care about individual connections; ie. it’s “stateless” with respect to the traffic. sshuttle is the opposite of stateless; it tracks every single connection.
You could compare sshuttle to something like the old Slirp program, which was a userspace TCP/IP implementation that did something similar. But it operated on a packet-by-packet basis on the client side, reassembling the packets on the server side. That worked okay back in the “real live serial port” days, because serial ports had predictable latency and buffering.
But you can’t safely just forward TCP packets over a TCP session (like ssh), because TCP’s performance depends fundamentally on packet loss; it must experience packet loss in order to know when to slow down! At the same time, the outer TCP session (ssh, in this case) is a reliable transport, which means that what you forward through the tunnel never experiences packet loss. The ssh session itself experiences packet loss, of course, but TCP fixes it up and ssh (and thus you) never know the difference. But neither does your inner TCP session, and extremely screwy performance ensues.
sshuttle assembles the TCP stream locally, multiplexes it statefully over an ssh session, and disassembles it back into packets at the other end. So it never ends up doing TCP-over-TCP. It’s just data-over-TCP, which is safe.
Requirements
Client side Requirements
- sudo, or root access on your client machine. (The server doesn’t need admin access.)
- Python 2.7 or Python 3.5.[3]
Server side Requirements
- Server requirements are more relaxed, however it is recommended that you use Python 2.7 or Python 3.5.
Installation
- From APT:
sudo apt-get update && sudo apt-get -y install sshuttle && sudo apt-get clean
- From PyPI:
sudo pip install sshuttle
- Clone from git:
git clone https://github.com/sshuttle/sshuttle.git
sudo ./setup.py install
- Installing sshuttle on your Mac:
brew install sshuttle
Usage
Finally we can get down to actually using sshuttle! It’s flexible enough to do fancier things, for forwarding all traffic basic command looks like this:
sshuttle -r username@sshserver 0.0.0.0/0
- Use the
sshuttle -rparameter to specify a remote server.
- By default sshuttle will automatically choose a method to use. Override with the
sshuttle --methodparameter.
- There is a shortcut for 0.0.0.0/0 for those that value their wrists:
sshuttle -r username@sshserver 0/0
If you would also like your DNS queries to be proxied through the DNS server of the server you are connect to:
sshuttle --dns -r username@sshserver 0/0
That’s it! Now your local machine can access the remote network as if you were right there. And if your “client” machine is a router, everyone on your local network can make connections to your remote network.[4]
Conclusion
Admittedly, sshuttle takes a bit more work than other solutions to get up and running, but the security it provides gives peace of mind when forced to use insecure Wi-Fi networks.
Autor
- Kirill Trunov C11, Estonian IT College, 08-05-2017
