Skip to content

Instantly share code, notes, and snippets.

@leto
Created May 1, 2011 18:23
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save leto/950711 to your computer and use it in GitHub Desktop.
Save leto/950711 to your computer and use it in GitHub Desktop.
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
@Jieiku
Copy link

Jieiku 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
Copy link

Dave-ts 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
Copy link

Lykos153 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
Copy link

gromero 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
Copy link

gromero 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
Copy link

gromero commented May 10, 2017

I opened an issue here: sshuttle/sshuttle#150

@onajafi
Copy link

onajafi 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
Copy link

csselo commented Nov 22, 2018

any dns solution?

@thulasidhasan
Copy link

~$ 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
Copy link

--exclude

This solved my problem.
Thanks 👍

@jjtriff
Copy link

jjtriff 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 👍

@hsgg
Copy link

hsgg commented May 19, 2022

--exclude XXX.XXX.XX.XXX

Yup, thanks! 👍

@GDYendell
Copy link

GDYendell commented Oct 31, 2022

sshuttle <user>@<server-ip> --exclude <server-ip> ...

Thanks! 💯

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment