sshuttle v1.1.1 releases: Transparent proxy server
by do son · Published · Updated
sshuttle: where transparent proxy meets VPN meets ssh
sshuttle is the only program that solves the following common case:
- 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.
- The remote network has no VPN, or only stupid/complex VPN protocols (IPsec, PPTP, etc). Or maybe you are the admin and you just got frustrated with the awful state of VPN tools.
- 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.
- You can’t use openssh’s PermitTunnel feature because it’s disabled by default on openssh servers; plus it does TCP-over-TCP, which has terrible performance (see below).
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.
Changelog v1.1.1
- Make –sudoers option work properly, fix regression in v1.1.0 by @skuhl in #727
- Clarify –disable-ipv6 in man page. by @skuhl in #729
- Improve message when bind fails with a IPv6 address by @skuhl in #728
- Bump actions/setup-python from 2.3.1 to 2.3.2 by @dependabot in #730
- Bump pytest from 6.2.5 to 7.0.0 by @dependabot in #731
- Add tests for host name resolution by @mangano-ito in #734
- Allows wildcard host names as subnets by @mangano-ito in #735
- Bump pytest from 7.0.0 to 7.0.1 by @dependabot in #737
- Bump actions/setup-python from 2.3.2 to 3 by @dependabot in #741
- Bump actions/checkout from 2.4.0 to 3 by @dependabot in #743
- Fix typo by @lbausch in #739
- Remove –sudoers, improve –sudoers-no-modify by @skuhl in #745
- Bump pytest from 7.0.1 to 7.1.1 by @dependabot in #747
- Bump sphinx from 4.3.2 to 4.5.0 by @dependabot in #749
- Bump pytest from 7.1.1 to 7.1.2 by @dependabot in #753
- Bump sphinx from 4.5.0 to 5.0.0 by @dependabot in #761
- avoid moving/renaming the hosts file – fix docker container issue by @nikatlas in #759
- Bump sphinx from 5.0.0 to 5.0.1 by @dependabot in #762
- Bump actions/setup-python from 3 to 4 by @dependabot in #763
- fixed some spelling mistakes by @venthur in #766
- Bump sphinx from 5.0.1 to 5.0.2 by @dependabot in #768
- Bump setuptools-scm from 6.4.2 to 7.0.1 by @dependabot in #770
- Bump setuptools-scm from 7.0.1 to 7.0.2 by @dependabot in #771
- Fix incorrect permissions for /etc/hosts by @skuhl in #772
- Bump setuptools-scm from 7.0.2 to 7.0.3 by @dependabot in #773
- Bump setuptools-scm from 7.0.3 to 7.0.4 by @dependabot in #775
- Bump setuptools-scm from 7.0.4 to 7.0.5 by @dependabot in #776
- Bump sphinx from 5.0.2 to 5.1.0 by @dependabot in #780
- Bump sphinx from 5.1.0 to 5.1.1 by @dependabot in #783
- This test broke in Python3.11 by @venthur in #791
- all elements are strings by @venthur in #792
- Replace setuptools_scm with bump2version by @venthur in #793
- Bump pytest from 7.1.2 to 7.1.3 by @dependabot in #795
Install
sudo pip install sshuttle
or
git clone https://github.com/sshuttle/sshuttle.git
cd sshuttle
sudo ./setup.py install
Usage
Forward all traffic:
sshuttle -r username@sshserver 0.0.0.0/0
- Use the sshuttle -r parameter to specify a remote server.
- By default, sshuttle will automatically choose a method to use. Override with the sshuttle –method parameter.
- 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 connected to:
sshuttle –dns -r username@sshserver 0/0
The above is probably what you want to use to prevent local network attacks such as Firesheep and friends. See the documentation for the sshuttle –dns parameter.
Copyright 2016, Brian May