Skip to content

Instantly share code, notes, and snippets.

@leto leto/gist:950711
Created May 1, 2011

Embed
What would you like to do?
Hard to reproduce sshuttle bug
$ ./sshuttle --dns -r leto@example.com 0/0 -vv
Starting sshuttle proxy.
Binding: 12300
Listening on ('127.0.0.1', 12300).
DNS listening on ('127.0.0.1', 12300).
[local sudo] Password:
Sorry, try again.
[local sudo] Password:
firewall manager ready.
c : connecting to server...
c : executing: ['ssh', 'leto@example.com', '--', 'P=python2; $P -V 2>/dev/null || P=python; "$P" -c \'import sys; skip_imports=1; verbosity=2; exec compile(sys.stdin.read(764), "assembler.py", "exec")\'']
c : > channel=0 cmd=PING len=7 (fullness=0)
server: assembling 'cmdline_options.py' (29 bytes)
server: assembling 'helpers.py' (693 bytes)
server: assembling 'ssubprocess.py' (13702 bytes)
server: assembling 'ssnet.py' (5100 bytes)
server: assembling 'hostwatch.py' (2242 bytes)
server: assembling 'server.py' (2380 bytes)
s: latency control setting = True
s: available routes:
s: 173.255.217.0/24
s: > channel=0 cmd=PING len=7 (fullness=0)
s: > channel=0 cmd=ROUTES len=17 (fullness=7)
s: Waiting: 1 r=[4] w=[5] x=[] (fullness=24/0)
s: Ready: 1 r=[] w=[5] x=[]
s: mux wrote: 15/15
s: mux wrote: 25/25
s: Waiting: 1 r=[4] w=[] x=[] (fullness=24/0)
c : connected.
Connected.
c : Waiting: 3 r=[3, 5, 9] w=[9] x=[] (fullness=7/0)
c : Ready: 3 r=[9] w=[9] x=[]
c : < channel=0 cmd=PING len=7
c : > channel=0 cmd=PONG len=7 (fullness=7)
c : < channel=0 cmd=ROUTES len=17
firewall manager: starting transproxy.
>> iptables -t nat -N sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -I OUTPUT 1 -j sshuttle-12300
>> iptables -t nat -I PREROUTING 1 -j sshuttle-12300
>> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8 -p tcp
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0 -p tcp --to-ports 12300 -m ttl ! --ttl 42
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest XX.7.43.10/32 -p udp --dport 53 --to-ports 12300 -m ttl ! --ttl 42
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest XX.7.33.10/32 -p udp --dport 53 --to-ports 12300 -m ttl ! --ttl 42
c : mux wrote: 15/15
c : mux wrote: 15/15
c : Waiting: 3 r=[3, 5, 9] w=[] x=[] (fullness=14/0)
Write failed: Broken pipe
c : Ready: 3 r=[9] w=[] x=[]
firewall manager: undoing changes.
>> iptables -t nat -D OUTPUT -j sshuttle-12300
>> iptables -t nat -D PREROUTING -j sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -X sshuttle-12300
c : fatal: server died with error code 255
@xekon

This comment has been minimized.

Copy link

commented Aug 14, 2016

I was able to reproduce the code 255 today, I connected to an ssh server using a dynamic dns service, and got a code 255, I then connected using the IP directly and got client: Connected.

@Dave-ts

This comment has been minimized.

Copy link

commented Apr 13, 2017

I don't have any idea why this bug happens but I can reproduce it reliably. I use the following line to connect to the remote server

sshuttle -r name@ip.address.or.domain 0/0 -vv --dns

I boot the client computer (currently xubuntu 16.04 but same thing happened in 14.04 and forward) the first time I attempt to connect to the server using the line listed above, the error occurs. All subsequent attempts succeed.

To reproduce the error condition, simply need to reboot the computer and connect again.

I thought maybe it might have something to do with not having permissions to rewrite the ip tables so I tried timing out the sudo auth using sudo -k but that made no difference.

I tried waiting several hours with all terminals closed (bi-product of afk) and then connecting again. no error occurs.

Simply rebooting the computer will result in the error occurring again on initial connection attempt.

@Lykos153

This comment has been minimized.

Copy link

commented Apr 19, 2017

It seems to occur when using --dns option and a domain that has not yet been resolved. It works fine after first connecting to the server via ssh or sshuttle without the --dns option.

@gromero

This comment has been minimized.

Copy link

commented May 10, 2017

Hi. I can reproduce that w/o --dns. Any update on that? Do we have an issue opened for that bug? Thanks.

@gromero

This comment has been minimized.

Copy link

commented May 10, 2017

I get:
c : SW#10:192.168.122.224:52642: error was: nowrite: [Errno 107] Transport endpoint is not connected before it crashes...

@gromero

This comment has been minimized.

Copy link

commented May 10, 2017

I opened an issue here: sshuttle/sshuttle#150

@onajafi

This comment has been minimized.

Copy link

commented Oct 7, 2018

This fixed the problem for me:
I added the --exclude XXX.XXX.XX.XXX option, where the Xs are the IP addresses of the server.
Here is a link to the original answer:
https://www.reddit.com/r/archlinux/comments/7kxdvw/trouble_running_sshuttle_these_days/

@csselo

This comment has been minimized.

Copy link

commented Nov 22, 2018

any dns solution?

@thulasidhasan

This comment has been minimized.

Copy link

commented Nov 23, 2018

~$ sshuttle --dns -vr user@xx.xxx.xx.xxx 0/0 --ssh-cmd 'ssh -i public.pem'
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 3.5.2
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: True
TCP redirector listening on ('127.0.0.1', 12300).
DNS listening on ('127.0.0.1', 12300).
Starting client with Python version 3.5.2
c : connecting to server...
Starting server with Python version 2.7.6
s: latency control setting = True
s: available routes:
s: 2/10.8.0.0/24
s: 2/10.8.0.2/32
s: 2/10.10.8.0/22
s: 2/192.168.0.0/22
c : Connected.
firewall manager: setting up.

iptables -t nat -N sshuttle-12300
iptables -t nat -F sshuttle-12300
iptables -t nat -I OUTPUT 1 -j sshuttle-12300
iptables -t nat -I PREROUTING 1 -j sshuttle-12300
iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8 -p tcp
iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0 -p tcp --to-ports 12300 -m ttl ! --ttl 42
iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 127.0.1.1/32 -p udp --dport 53 --to-ports 12300 -m ttl ! --ttl 42
packet_write_wait: Connection to 49.206.24.241 port 22: Broken pipe
firewall manager: undoing changes.
iptables -t nat -D OUTPUT -j sshuttle-12300
iptables -t nat -D PREROUTING -j sshuttle-12300
iptables -t nat -F sshuttle-12300
iptables -t nat -X sshuttle-12300
c : fatal: server died with error code 255

any solution for this. I can able to ssh by following the below command but sshuttle is not working
ssh -i public.pem user@xx.xxx.xx.xxx

@rafaelweingartner

This comment has been minimized.

Copy link

commented Dec 24, 2018

--exclude

This solved my problem.
Thanks 👍

@jjtriff

This comment has been minimized.

Copy link

commented Aug 14, 2019

This fixed the problem for me:
I added the --exclude XXX.XXX.XX.XXX option, where the Xs are the IP addresses of the server.
Here is a link to the original answer:
https://www.reddit.com/r/archlinux/comments/7kxdvw/trouble_running_sshuttle_these_days/

This totally makes sense, I was getting the error broken pipe and server died with error code 255, but of course, the connection to the server was lost as soon as the firewall started enforcing every connections, including the current ssh client.

wow Thanks 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.