
Show HN: A simple SSH VPN client - ivanilves
https://github.com/ivanilves/xiringuito
======
lima
How is it different from sshuttle, which does not need remote root?

[https://github.com/apenwarr/sshuttle](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](http://sites.inka.de/bigred/devel/tcp-tcp.html)

~~~
ivanilves
Well, there are some differences between sshuttle and xiringuito:

1) xiringuito is great for UDP. I had issues with RTP streams (UDP, random
ports) running over sshuttle , though they run perfectly over SSH tun/tap.

2) I can run low-level non-TCP, non-UDP, IP protocols like OSPF over tunnels I
create with tun/tap.

3) xiringuito does not require python. Not everybody loves python.

Overally I am a fan of sshuttle, but the way it's made prevented me from using
it in a few cases, so I created xiringuito ;)

------
sharjeelsayed
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

ssh -o StrictHostKeyChecking=no -C -f -q -D 7070 username@servername sleep 10
; "/cygdrive/c/PortableApps/GoogleChromePortable/GoogleChromePortable.exe"
\--proxy-server="socks5://localhost:7070" &

~~~
zenlikethat
Probably shouldn't turn off StrictHostKeyChecking. SSH will prompt to confirm
the fingerprint if needed.

------
okket
ssh has a SOCKS4/5 client/server built in, so why not use it?

    
    
       ssh -D [bind_address:]port <server>

~~~
Daviey
Not every application supports SOCKS natively. The other options are
transparent, with the option of declaring subsets to route over the tunnel.

~~~
sattoshi
You can configure most systems to use SOCKS everywhere

~~~
deathanatos
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.)

------
contingencies
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.

~~~
ivanilves
Yes... But not all apps are web ;) We should also think about ones using non-
HTTP TCP and UDP.

~~~
contingencies
Well you can use SOCKS or OpenVPN over SSH quite easy too. However, in my
experience these are are less reliable, at least in China for GFW.

~~~
riskable
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!

OpenVPN is the best!

~~~
contingencies
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.

~~~
subway
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)

~~~
peterwwillis
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).

------
ivanilves
[https://github.com/ivanilves/xiringuito/issues/42](https://github.com/ivanilves/xiringuito/issues/42)

`sshuttle` & `xiringuito` differences well explained (I hope).

