Terminal broken with python3.12

[kritag]

I recetly upgraded from Fedora 38 to Fedora 39 which bumps the python version from 3.11.6 to 3.12.

This change has the terminal output of running sshuttle hanging, i.e. CTRL+C not working, pasting not working. I discovered this on my upgraded system, and to rule out any local configuration issues, I booted up a liveiso with fedora 39 workstation, and the issue persisted there:

Then I tinkered with python 3.11, but getting this error running sshuttle as a non-root user (I don't know how to actually fix this in python 3.11):

Starting sshuttle proxy.
Traceback (most recent call last):
File "/home/user/.local/lib/python3.11/site-packages/sshuttle/__main__.py", line 4, in <module>
     sys.exit(main())
              ^^^^^^
   File "/home/user/.local/lib/python3.11/site-packages/sshuttle/cmdline.py", line 26, in main
     return firewall.main(opt.method, opt.syslog)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/user/.local/lib/python3.11/site-packages/sshuttle/firewall.py", line 97, in main
     stdin, stdout = setup_daemon()
                     ^^^^^^^^^^^^^^
   File "/home/user/.local/lib/python3.11/site-packages/sshuttle/firewall.py", line 68, in setup_daemon
     os.setsid()
 PermissionError: [Errno 1] Operation not permitted
 fatal: ['sudo', '-p', '[local sudo] Password: ', '/usr/bin/env', 'PYTHONPATH=/home/user/.local/lib/python3.11/site-packages', '/usr/bin/python3.11', '/home/user/.local/lib/python3.11/site-packages/sshuttle/__main__.py', '-v', '--method', 'auto', '--firewall', '--syslog'] returned 1

Then I got root working with pip and python 3.11 and my script wrapping sshuttle is now working as expected (I also tried this on the liveISO with 3 reboots trying sshuttle 0.78, sshuttle version 1.1.1 from pip and sshuttle version 1.1.1 from dnf):

My question is therefore, how can we get a working sshuttle on python 3.12? Any temporary fix available or a permanent fix for python 3.12? I can technically get this to work as is on version 3.12, but I need to paste stuff into the terminal (as I was able to do before, and in the last example as root) and it's an unwanted behavior.

[kritag]

I can add that I get the same results in an arch VM running gnome.

[dancek]

I've had the same issue on Arch Linux for the couple of weeks I've been using sshuttle.

[dancek]

After starting sshuttle as daemon I have terminal settings like this:

$ stty
speed 38400 baud; line = 0;
                           -brkint -icrnl -imaxbel iutf8
                                                        -opost
                                                              -isig -iexten

Running stty cooked or reset fixes a lot but not all of it. Eg. I still can't close the terminal with ^D.

[dancek]

My python version is actually 3.11.5 so this is probably caused by something else than python 3.12.

I also noticed that the process ID indicated in the file specified by --pidfile is not attached to a terminal, but some of the other processes spawned are attached to pts/0. So that explains why ctrl-D doesn't close the terminal window.

So I guess messing up the terminal is one bug and not properly disowning daemon processes is another bug.

[Xazziri]

I have the same issue running on Ubuntu 23.10 with Python 3.11.4-5, using either the provides sshuttle version 1.0.5-1ubuntu4 (from the repo's) or 1.1.1-1 installed as .deb package from Sid. This behavior happens using either the console, terminator or xfce4-terminal.

[kritag]

Fwiw it works on a fedora 38 liveISO, while (as stated initially) the issue at least for me is on fedora 39 and arch with python 3.12.

[dancek]

Arch still ships Python 3.11.5: https://archlinux.org/packages/core/x86_64/python/

…

On Wed, 15 Nov 2023, 13.55 kritag, ***@***.***> wrote: Fwiw it works on a fedora 38 liveISO, while (as stated initially) the issue at least for me is on fedora 39 and arch with python 3.12. — Reply to this email directly, view it on GitHub <#909 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB35ESEHCX735NNXNF2S3LYESUTLAVCNFSM6AAAAAA7DNKVCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSGQYDGMRTGI> . You are receiving this because you commented.Message ID: ***@***.***>

[gnubibi33]

Same issue for me on Debian SID with python 3.11.6-3

[skuhl]

Have you tried making sure that all versions of sshuttle are removed (installed via the system package manager, pip, etc) and then only installing a recent version of sshuttle? In the past, I've found that I've thought I was using one version of sshuttle but was actually using another. Or, there were multiple versions installed and being mixed in unexpected ways.

I can't reproduce this problem on Ubuntu 23.10 with either python 3.11 or 3.12 with sshuttle 1.1.1.

A similar sounding problem was fixed in #712 which should be in sshuttle 1.1.0 and could have caused garbled terminal output and Ctrl+C not to work. In #712 you can also find some links to other reported issues near the bottom.

Another option would be to try using the visudo command to disable the use_pty option in /etc/sudoers just to see if it fixes the problem. use_pty is a setting that has recently been turned on in many distributions and led to the fix in #712. I believe there are security reasons why use_pty has become the preferred default.

[kritag]

Thanks for the info! I was able to get this working on my current workstation running Arch by uncommenting #Defaults !use_pty from /etc/sudoers. I suspect this is also the case for Fedora, but thanks anyway for pointing to a solution!

If most distros have this as a default now, is it possible to somehow fix sshuttle to accomocate for people not having this uncommented in their /etc/sudoers?

[dancek]

Good to finally have some pointers on what's happening. Indeed, #712 fixes the use_pty behavior in the "normal" use case but running as daemon (-D) seems broken. Setting !use_pty for sudo is a workaround but it's not optimal.

Running stty cooked fixes the terminal behavior after starting a daemon, and sshuttle could probably do something like this with termios when daemonizing itself.

The daemonized sshuttle master process is using the TTY of the terminal you start it from, whether use_pty is used or not. So after daemonizing the typical terminal emulator won't quit even when you exit the shell, as its PTY is still being used. I guess this warrants another issue.

[gnubibi33]

Setting Defaults !use_pty and it's working now :)

Thx !

[skuhl]

Indeed, #712 fixes the use_pty behavior in the "normal" use case but running as daemon (-D) seems broken. Setting !use_pty for sudo is a workaround but it's not optimal.

Thanks for the info. I probably didn't check that #712 worked with daemon mode. I did check that using #712 makes sshuttle work when running normally from the command line regardless of the use_pty setting. I'll try to take a look at daemon mode to see if I can reproduce and fix the problem.

[skuhl]

use_pty documentation from the man page says https://www.man7.org/linux/man-pages/man5/sudoers.5.html

A malicious program run under sudo may be capable of injecting commands into the user's terminal or running a background process that retains access to the user's terminal device even after the main program has finished executing. By running the command in a separate pseudo-terminal, this attack is no longer possible. This flag is on by default for sudo 1.9.14 and above.

sudo 1.9.14 appears to have been released around June 2023. It is unclear to me if this has other impacts besides the garbled terminal output.

[dancek]

PR #922 fixes this issue in my use case, but I'm unsure if it's the best possible implementation. @skuhl I'm hoping you could review the PR if you have time, please!

[victornoel]

Hi, is there a plan to soon release a new version of sshuttle so that we can benefit from this fix? Cheers :)

[brianmay]

Version 1.1.2 now released.

[skuhl]

Maybe we should tag the release in github too? Right now, 1.1.1 shows up on the right side as the latest release.

[brianmay]

1.1.2 was tagged, but I forgot to generate a release for 1.1.2. Now fixed.