Description of problem: sshuttle fails with the sequence below after it asks for the password: me's password: Traceback (most recent call last): File "<string>", line 1, in ? File "assembler.py", line 18, in ? AttributeError: 'unicode' object has no attribute 'rpartition' client: fatal: server died with error code 1 Version-Release number of selected component (if applicable): sshuttle-0.77.2-1.fc23.noarch I used "dnf downgrade sshuttle" to restore the previous version, which is sshuttle-0-11.20120810git9ce2fa0.fc23.noarch How reproducible: It happens every time. Steps to Reproduce: 1. run sshuttle and try to connect 2. it happens after asking for the password, so you have to connect using a real account 3. Actual results: sshuttle fails with AttributeError: 'unicode' object has no attribute 'rpartition' Expected results: Working connection Additional info: I think that the bad line is in /usr/lib/python2.7/site-packages/sshuttle/assembler.py
Can you tell us the full command line you are using (feel free to replace ip's/nets, etc). Also, does your password happen to contain unicode characters?
I am running sudo sshuttle -r user:9000 10.0.0.0/16 The password is only printable 7 bit ascii characters. $ sudo sshuttle -r xxx.x.x:9xxx 10.0.0.0/16 xxx.x.x's password: Traceback (most recent call last): File "<string>", line 1, in ? File "assembler.py", line 18, in ? AttributeError: 'unicode' object has no attribute 'rpartition' client: fatal: server died with error code 1
Hi, Same problem here: sshuttle -v -r user 10.0.0.0/16 192.168.0.0/24 Starting sshuttle proxy. firewall manager: Starting firewall with Python version 2.7.10 firewall manager: ready method name nat. IPv6 enabled: False UDP enabled: False DNS enabled: False TCP redirector listening on ('127.0.0.1', 12300). Starting client with Python version 2.7.10 c : connecting to server... X11 forwarding request failed on channel 0 Traceback (most recent call last): File "<string>", line 1, in ? File "assembler.py", line 18, in ? AttributeError: 'unicode' object has no attribute 'rpartition' c : fatal: server died with error code 1
Good afternoon. Updated to f23 recently and I'm having this exact same issue: sshuttle simply does not work. By downgrading the package, it works. To reproduce: just try to use it. Best regards.
Hello. Some more insight follows. It works if I do sshuttle to a recent system, like f23. But if I try to RHEL 5 or RHEL 6, it just fails. Seems to me the new version always expects python 3 to be present on the other side? If so, the new version is useless for anyone that has to manage older (but still supported) systems.
Yes, the new sshuttle upstream release which we have moved to currently requires python either 2.7 or 3.5 on both ends. There is work on supporting 2.4 on the server end: https://github.com/sshuttle/sshuttle/pull/81 .. but its not yet complete.
[The previous comment came while I was writing this.] On my F23 laptop, I tested sudo sshuttle -v -r user.com 10.0.0.0/16 I could connect to CentOS 7 but not to CentOS 5. Neither of these servers have python 3 installed. The "Starting server with Python version 2.7.5" line shows that it is running python2 on the target. The CentOS 7 server has Python 2.7.5, while the CentOS 5 server has Python 2.4.3. It also works with my CentOS 6 server as the target, which has Python 2.6.6. It looks like rpartition was added in Python 2.5. https://bytes.com/topic/python/answers/537988-new-string-method-2-5-partition I think that the problem is that the updated sshuttle uses rpartition which requires a target with Python 2.5 or later. Could the new sshuttle code be written to use another method to implement the rpartition or to revert to the old sshuttle code with older versions of python? --- When the target is CentOS 7, I get sudo sshuttle -v -r user@centos7 10.0.0.0/16 Starting sshuttle proxy. firewall manager: Starting firewall with Python version 2.7.10 firewall manager: ready method name nat. IPv6 enabled: False UDP enabled: False DNS enabled: False TCP redirector listening on ('127.0.0.1', 12300). Starting client with Python version 2.7.10 c : connecting to server... user@centos7's password: Starting server with Python version 2.7.5 s: latency control setting = True s: available routes: s: 2/10.0.0.0/16 s: 2/192.168.122.0/24 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 REDIRECT --dest 10.0.0.0/16 -p tcp --to-ports 12300 -m ttl ! --ttl 42 >> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8 -p tcp When the target is CentOS 5, I get sudo sshuttle -v -r user@centos5 10.0.0.0/16 Starting sshuttle proxy. firewall manager: Starting firewall with Python version 2.7.10 firewall manager: ready method name nat. IPv6 enabled: False UDP enabled: False DNS enabled: False TCP redirector listening on ('127.0.0.1', 12300). Starting client with Python version 2.7.10 c : connecting to server... user@centos5's password: Traceback (most recent call last): File "<string>", line 1, in ? File "assembler.py", line 18, in ? AttributeError: 'unicode' object has no attribute 'rpartition' c : fatal: server died with error code 1 --- Section of new /usr/lib/python2.7/site-packages/sshuttle/assembler.py content = z.decompress(stdin.read(nbytes)) module = imp.new_module(name) parent, _, parent_name = name.rpartition(".") if parent != "": setattr(sys.modules[parent], parent_name, module) code = compile(content, name, "exec") exec(code, module.__dict__) sys.modules[name] = module Corresponding section of old /usr/share/sshuttle/assembler.py content = z.decompress(sys.stdin.read(nbytes)) exec compile(content, name, "exec") # FIXME: this crushes everything into a single module namespace, # then makes each of the module names point at this one. Gross. assert(name.endswith('.py')) modname = name[:-3] mainmod.__dict__[modname] = mainmod
OK, I have updated the packages to a current git snapshot, and added a patch to enable support for older python on the server end. This is the build of those packages. When it's complete, please test: http://koji.fedoraproject.org/koji/taskinfo?taskID=13540955
sshuttle-0.77.3-0.1.20160402git6e15e691.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-0d6542f05a
sshuttle-0.77.3-0.1.20160402git6e15e691.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-844f8350f4
The package can be pulled from this url if you wish to test it before it's available in the updates-testing repo: https://kojipkgs.fedoraproject.org//work/tasks/964/13540964/sshuttle-0.77.3-0.1.20160402git6e15e691.fc23.noarch.rpm
sshuttle-0.77.3-0.1.20160402git6e15e691.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-0d6542f05a
sshuttle-0.77.3-0.1.20160402git6e15e691.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-844f8350f4
It's working. Thanks, Fernando Gomes
(In reply to Fernando Gomes from comment #14) > It's working. > > Thanks, > Fernando Gomes You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-0d6542f05a
Folks, thanks for adding feedback. But please be aware that if you add feedback without adding karma, it doesn't result in the package being pushed to updates - right now 3 of you left feedback, but only one of you increased the karma.
It is still broken for me when connecting to CentOS4 but it is now OK for CentOS5. $ uname -a Linux laptop.example.com 4.4.6-300.fc23.x86_64 #1 SMP Wed Mar 16 22:10:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux $ rpm -q sshuttle sshuttle-0.77.3-0.1.20160402git6e15e691.fc23.noarch $ sudo sshuttle -v -r william@centos4 10.0.0.0/16 Starting sshuttle proxy. firewall manager: Starting firewall with Python version 2.7.10 firewall manager: ready method name nat. IPv6 enabled: False UDP enabled: False DNS enabled: False TCP redirector listening on ('127.0.0.1', 12300). Starting client with Python version 2.7.10 c : connecting to server... william@centos4's password: Traceback (most recent call last): File "<string>", line 1, in ? File "assembler.py", line 18, in ? AttributeError: 'unicode' object has no attribute 'rsplit' c : fatal: server died with error code 1 $ On centos4: $ uname -a Linux centos4.example.com 2.6.9-103.EL #1 Fri Dec 9 04:15:51 EST 2011 x86_64 x86_64 x86_64 GNU/Linux $ cat /etc/redhat-release CentOS release 4.9 (Final) $ python -V Python 2.3.4 $
(In reply to William Bader from comment #17) > It is still broken for me when connecting to CentOS4 but it is now OK for > CentOS5. > Yeah, we're not going to fix that. RHEL4/CentOS4 has ancient python, and is no longer supported.
>is no longer supported. That is a pity because the previous version of sshuttle could connect to CentOS 4 servers. I tried changing assembler.py to use rfind() instead of rsplit(), but then it failed with Traceback (most recent call last): File "<string>", line 1, in ? File "assembler.py", line 25, in ? File "sshuttle.hostwatch", line 10, in ? ImportError: No module named subprocess c : fatal: server died with error code 1 Is there a reason why the new version can't use "try" to "import compat.ssubprocess as ssubprocess" if "import subprocess as ssubprocess" fails? William
sshuttle-0.77.3-0.1.20160402git6e15e691.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to William Bader from comment #19) > >is no longer supported. > > That is a pity because the previous version of sshuttle could connect to > CentOS 4 servers. > > I tried changing assembler.py to use rfind() instead of rsplit(), but then > it failed with > > Traceback (most recent call last): > File "<string>", line 1, in ? > File "assembler.py", line 25, in ? > File "sshuttle.hostwatch", line 10, in ? > ImportError: No module named subprocess > c : fatal: server died with error code 1 > > Is there a reason why the new version can't use "try" to "import > compat.ssubprocess as ssubprocess" if "import subprocess as ssubprocess" > fails? I'm afraid we won't be patching this downstream in Fedora, but you could petition upstream to support python 2.3 if you think it's important. If upstream support python 2.3, so will Fedora.
sshuttle-0.77.3-0.1.20160402git6e15e691.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.