Sshuttle - tunnel all your traffic through ssh
github.com
github.com
I tried sshuttle awhile ago and abandoned it because of this. The only thing worse than no security is a false sense of security.
Security is never just a software you install, it also depends on you, knowing, what you do.
But I have not tried it.
Out of curiosity, is it theoretically possible to route other kinds of traffic over this, e.g. UDP, ICMP(ping)? Thanks.
By the way, (open-)ssh itself supports a tun/tap VPN mode (-w I believe) that creates actual network interfaces on the two endpoints, and thus can transport any IP traffic. It needs to be explicitly enabled on the server, and needs kernel tun/tap support, which is usually missing on VPSes that don't let you run your own kernel (modules).
And nobody never notified me of any security flaws in my key exchange,
And nobody ever found any security flaws in my key exchange,
Regarding SSHuttle itself, I really liked it! (coming from someone who does all his browsing with ssh -D)
pppd updetach noauth pty "ssh root@example.com pppd nodetach notty noauth" ipparam 192.168.1.100:192.168.1.2
How did you get it to work?
http://library.linode.com/networking/openvpn/
Super easy to do even if you are a linux noob.
In a normal tunnel setup, one tunnels at the IP layer, and dumps all IP packets into the tunnel. At the far end of the tunnel, packets are sent onwards based on the far end's routing table. Things like DNS "just work" because everything happens at a layer below TCP and UDP. In this system, he's making it work for each non-tcp using layer 4 protocol separately, leading to weirdness like rewriting /etc/hosts.
For tcp, he's nating all traffic locally to a local server, which then multiplexes all incoming traffic into the ssh connection. The remote side then unmultiplexes the data. I don't fully understand how this avoids tcp over tcp. Maybe I'm dumb. [edit: yeah, I'm dumb. the tcp connection is terminated at the local server, the contents are pumped over the ssh connection, and the remote side opens a new tcp connection]
I wrote this mostly because I read the readme and went "but how does it work?".
The "--auto-hosts" option you linked to is not the same as the "--dns" option. auto-hosts doesn't capture DNS at all; instead it just adds to your local /etc/hosts. I use this feature much more than --dns, actually, because unlike --dns, it works great if you have multiple tunnels to different offices open at once. (You get all the hostnames from all the offices.)
sshuttle was originally designed to VPN into an office and forward a couple of subnets over. In that case, you often don't want to use the remote DNS server, you just want to know the remote hostnames, because most of your DNS lookups have nothing to do with the remote server. Hence --auto-nets and --auto-hosts.
Nowadays it seems like sshuttle is mostly being used to counter things like Firesheep, which means you want to forward all your traffic to a remote server. In that case --dns - which forwards all your port 53 traffic over the VPN - is preferable.
We could actually do all the other UDP ports the same way we do --dns. We just don't, because I haven't needed it and nobody else has submitted a patch.
I haven't bothered to look at how this is actually implemented, so I can't comment on how it actually works.
It makes sense to me that it should perform badly, and it probably does for uses cases with a lot of traffic, but for an average user on a laptop, a TCP based VPN is fine.
TCP-over-TCP not "broken" in the sense that the sessions will randomly drop or your kernel will crash or anything. It's just that doing it correctly is much better.
Mind you, given the prevalence of bufferbloat (mostly caused by misdesigned routers/DSL/cablemodems) nowadays, interactive performance already largely sucks when you're transferring large files. So you might not even notice a difference.
Bufferbloat makes me sad :(
Using it over hotel wifi as I'm typing!
Explanation - as usual, my company works on a shared LAN which goes through a single internet connection. To test some applications, we have to be able to receive postbacks (on our developer machines) through 3'rd party services. The best way we found was to have an OpenVPN server running somewhere. Each developer connects to the VPN server and receives a private IP-address. All postbacks go to the VPN server and are then routed through nginx to the correct developer machine (on the private IP address).
VPN is a pain to setup and configure - can something like this be used instead ? The question really is - how does nginx forward requests to the correct developer machine.
It's a generic "expose my local HTTP server to the Internet" tool, designed to be really convenient and easy to set up (assuming you already have a local HTTP server). If I understand you correctly, it may be exactly what you are looking for.
It's FOSS so if you don't want to use the service (my startup!) you can roll your own. :-) But if you're looking for convenience, the service is probably hard to beat. Come chat on #pagekite on Freenode if you've got any questions!
I suppose we will sign up sooner or later - 10 Euro isnt too expensive.
Can I have a ww-drt install act as a client with Sshuttle and install a public key to require no login?
A few years back, I wrote a multiplexer / tunneler similar to Sshuttle in Python for a "Go To My PC" style web service. We wanted to tunnel over ssh, but had problems automating the client key generation and first-time connection. So we went with SSL. That and the cross platform requirement (most clients were running Windows) really took the fun out of it.
Also, if you start streaming Hulu through a shell account, there is a good chance that your shell account provider will notice and possibly get angry.
> ssh -D localhost:8888 <you@yourvps.com>
then enter localhost:8888 as your socks proxy in your web browser.
Just so you know, for anything that works over a socks proxy you can already do that easily with ssh (using the -D switch, check the manpage). You then need to configure your client app to use it (e.g. if doing ssh -D locally, in google's chrome, go to tools -> preferences -> under the hood -> proxy settings -> manual, then fill with localhost and the port number)
This is how you use it:
git clone git://github.com/apenwarr/sshuttle on your client machine. You'll need root or sudo access, and python needs to be installed.
./sshuttle -r username@sshserver 0.0.0.0/0 -vv
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.
You don't need to install sshuttle on the remote server; the remote server just needs to have python available. sshuttle will automatically upload and run its source code to the remote python interpreter.
This creates a transparent proxy server on your local machine for all IP addresses that match 0.0.0.0/0. (You can use more specific IP addresses if you want; use any number of IP addresses or subnets to change which addresses get proxied. Using 0.0.0.0/0 proxies everything, which is interesting if you don't trust the people on your local network.)
Any TCP session you initiate to one of the proxied IP addresses will be captured by sshuttle and sent over an ssh session to the remote copy of sshuttle, which will then regenerate the connection on that end, and funnel the data back and forth through ssh.
Fun, right? A poor man's instant VPN, and you don't even have to have admin access on the server.