Streisand: Modular Streisand: optional sshuttle role with dedicated user

[gimoh]

Expected behavior:

sshuttle should be available as a tunnelling method

Actual Behavior:

sshuttle support has been removed by commit aa69d23

Reason for request:

sshuttle is a very useful tunnelling method, with the most minimal requirements (no specialised VPN client software required, only SSH).

It is also most reliable in my experience. I've had issues with pretty much every VPN and debugging is usually a PITA, while sshuttle just works.

Could support be restored please?

[wzyboy]

sshuttle invokes /bin/sh -c python xxx on the remote server. This behavior goes against the intention of restricting the "forward" user to be used as port forwarding purposes only.

[cpu]

Hi @gimoh,

Sorry to hear that you were using sshuttle. What client devices were you using to access the sshuttle server?

I've had issues with pretty much every VPN and debugging is usually a PITA, while sshuttle just works.

We would be happy to help you debug the other options so that they can work more reliably for you.

[gimoh]

What would you say for creating another user for sshuttle, possibly making it optional like the other services?

[cpu]

What would you say for creating another user for sshuttle, possibly making it optional like the other services?

That's an option but so far only you have expressed that you miss sshuttle. I apologize for breaking your workflow but I'm also hesitant to bring back more code & additional services since we struggle to maintain the options that remain available with our current free time & # of active maintainers.

I would need to be convinced that we're taking the sshuttle maintenance burden to help a number of users that can't use the existing services. That's why I was asking more about devices you were using and whether we could figure out why the other services don't work well for you. If possible the best outcome would be one where you can continue to use Streisand but where we don't have to add anymore code to maintain :-)

[gimoh]

Well, if you look at changes in aa69d23 they are mostly to do with removing sshuttle from docs, code-wise sshuttle support actually only means removing the command="{{ ssh_force_command }}" snippet from playbooks/roles/ssh-forward/tasks/main.yml.

In any case, it is of course up to you what you want to support. All I'm saying is sshuttle is a perfectly viable tunnelling solution, works perfectly for me in an environment with a restrictive firewall and a proxy. Sure enough, I only know about one person other than me using it, so it you have no users for it, surprising as it is, that's fair enough to remove it.

I will give VPN clients another try when I get a moment, last time I tried in this environment I had issues with disconnects after a period of inactivity, I suspected the firewall/proxy to be the culprit but since it was outside my control I couldn't track it down reliably.

Depending on the decision you make, I'm happy enough to just revert that commit it in my own branch in the meantime.

[cpu]

Well, if you look at changes in aa69d23 they are mostly to do with removing sshuttle from docs, code-wise sshuttle support actually only means removing the command="{{ ssh_force_command }}" snippet from playbooks/roles/ssh-forward/tasks/main.yml.

You're right, I had thought there was a daemon component on the server-side but it appears that isn't the case. That makes the idea of reintroducing it as a modular role with a separate user more appealing.

All I'm saying is sshuttle is a perfectly viable tunnelling solution, works perfectly for me in an environment with a restrictive firewall and a proxy.

I appreciate you saying that, it's valuable to hear this feedback. We don't collect any kind of stats through Streisand so the anecdotes from users are key.

Depending on the decision you make, I'm happy enough to just revert that commit it in my own branch in the meantime.

You've warmed me to the idea of reintroducing it. I will try and submit a PR in the next few days.

[wzyboy]

Hi @gimoh ,

code-wise sshuttle support actually only means removing the command="{{ ssh_force_command }}" snippet from playbooks/roles/ssh-forward/tasks/main.yml.

it just occurred to me, that the fact sshuttle does not require a server-side daemon, just a noraml SSH user and a Python interpreter, means you could always use sshuttle with the default user. I mean, Ansible uses a user (by default ubuntu if you uses EC2) to ssh into the Streisand server, you could also use this user as the sshuttle user.

I'm happy enough to just revert that commit it in my own branch in the meantime.

So there is no need to revert any commits? Just change the sshuttle user from forward to ubuntu. :-)

[gimoh]

you could always use sshuttle with the default user

That's true, however that would effectively mean giving other sshuttle users root access.

In my case I could probably live with that, if someone breaks the server I could just delete it and re-build it. I still think it would be useful to mention sshuttle in the docs, this is what made me look into streisand in more depth in the first place, because I knew it supports something I already know works, and more so I could try other solutions too.

BTW, I have tried VPN clients again now. OpenVPN is the only possibility as I only have outbound access on 443/tcp and it has to go through a HTTP proxy. Unfortunately not having much luck, OpenVPN takes multiple tries to establish connection, the following is repeated multiple times in the log:

Attempting to establish TCP connection with [AF_INET]MYPROXY:3128 [nonblock]
TCP connection established with [AF_INET]MYPROXY:3128
TCP_CLIENT link local: (not bound)
TCP_CLIENT link remote: [AF_INET]MYPROXY:3128
WARNING: Bad encapsulated packet length from peer (21331), which must be > 0 and <= 1627 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition coul
Connection reset, restarting [0]
SIGUSR1[soft,connection-reset] received, process restarting

It usually eventually manages to establish the connection, however it still dies after a while. I'm going to investigate if that bad packet length could be the cause when I get a chance. So far I know it's something to do with that proxy.

In the meantime sshuttle is still the only reliable option for me.

[tiliarou]

@gimoh how did you specify the http proxy to openvpn ? In the gui setting window ?
I'm also behind authenticated http/https proxy, only allowing port 80 and 443. I connect to my streisand server with openvnp 443 file, and I specified the http proxy in the openvpn gui. Then when connecting, it asks me every time for my proxy username and password.

+1 to add back sshuttle.

[nopdotcom]

sshuttle does not require a server-side daemon, just a noraml SSH user and a Python interpreter, means you could always use sshuttle with the default user.

On systems like Vultr with no ubuntu user, my cloud-init script just aliases it to root with:

useradd --non-unique --uid 0 --gid 0 --home-dir /root -s /bin/bash ubuntu

I guess what I mean is that Unix usernames are pretty arbitrary, at least at this level.

[cpu]

@gimoh @tiliarou sshuttle is now present in master (but disabled by default). It can be enabled in the service configuration step.

Thanks for opening the issue!

[gimoh]

@cpu many thanks for this, really appreciated 😄

@tiliarou yes, exactly the same, connecting to openvpn over port 443 with proxy settings specified in NetworkManager VPN settings (I'm on Debian). So does this setup work OK for you? Do you get the _"Bad encapsulated packet length"_ warnings anyway?

[tiliarou]

@gimoh same setup but I'm under Win 7 x64 using openvpn 2.4.0.
Proxy specified via openvpn gui. I'm using the alternate profile (sslh)
It works fine and I don't get "Bad encapsulated packet length", I connect successfully to the proxy in TCP:

Sun Nov 05 17:58:51 2017 Attempting to establish TCP connection with [AF_INET]yy.yy.yy.yy:8080 [nonblock]

Sun Nov 05 17:58:51 2017 MANAGEMENT: >STATE:1509893931,TCP_CONNECT,,,,,,

Sun Nov 05 17:58:52 2017 TCP connection established with [AF_INET]yy.yy.yy.yy:8080

Sun Nov 05 17:58:52 2017 Send to HTTP proxy: 'CONNECT xx.xx.xx.xx:443 HTTP/1.0'

Sun Nov 05 17:58:52 2017 Send to HTTP proxy: 'Host: xx.xx.xx.xx:'

Sun Nov 05 17:58:52 2017 HTTP proxy returned: 'HTTP/1.1 407 Proxy Authentication Required'

Sun Nov 05 17:58:52 2017 Proxy requires authentication

[gimoh]

@tiliarou hmm I don't get those messages about stuff being sent to HTTP proxy, maybe my settings aren't quite correct, I'll check that out. Thanks, that's very useful.