| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This fixes #909 and is an alternative to the #922 pull request. When
sudo's use_pty is used with sshuttle, it causes issues with the
terminal. Pull request #712 contains some fixes for this problem.
However, when sshuttle is run with the --daemon option, it left the
user's terminal in a non-sane state. The problem appears to be related
to a socketpair that the firewall uses for communication. By setting
it up slightly differently (see changes to client.py and firewall.py),
the terminal state is no longer disrupted. This commit also changes
line endings of the printed messages from \r\n to \n. This undoes a
change introduced by pull request #712 and is no longer needed.
|
|
When we use sudo and start the firewall process, we should be able to
read standard in and find the string "READY". However, some
administrators use a wrapper around sudo to print warning messages
(instead of sudo's lecture feature) to standard out. This commit reads
up to 100 lines looking for "READY" instead of expecting it on the
first line.
I believe this should fix issue #916.
|
|
Having --dst-type LOCAL rules before DNS ones forces the usage of a
dnsmasq-like program to retrigger DNS requests directed locally
because they are fast-tracked through the firewall and ignored by
sshuttle.
As dns options documentation state that they capture the requests no
matter the server, and other methods and older versions behave
consistently, change the iptables rules to apply DNS ones first.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Removed a few lines of legacy code (to make it look more clean)
|
|
|
|
|
|
|
|
If we modify /etc/hosts, we read/copy the ownership and permissions
from the existing /etc/hosts before we make our new temporary file
which will eventually overwrite /etc/hosts. If we fail to retrieve the
permissions of the existing /etc/hosts file, we made the temporary
file owned by root 0o600 permissions. It should have 0o644 permissions
so that /etc/hosts has the correct permissions once we rename it.
It is unlikely many encoutered this bug since most machines have
/etc/hosts prior to sshuttle running and we should be able to read the
permission/ownership of that existing file.
|
|
|
|
|
|
This file has not been touched in years. And looks like it is broken,
e.g. listener.accept() is called after infinite loop.
|
|
BaseException includes exceptions like SystemExit, KeyboardInterrupt
and GeneratorExit that we should not be catching.
|
|
|
|
|
|
|
|
|
|
|
|
Allowing sshuttle to add/overwrite sudoers configuration file at
locations of the users' choosing adds complexity to the code compared
to asking users to install the sudo configuration themselves. It
requires sshuttle to make decisions about how much effort we put into
ensuring that the file is written to a proper location. The current
method relies on the 'realpath' program which is not installed on
MacOS by default.
There are serious problems when the sudo configuration is used to
allow a user to *only* run sshuttle as root (with or without a
password). First, that user could then use the --sudoers option to
give other users sudo privileges. Second, the user can run any command
as root because sshuttle accepts a --ssh-cmd parameter which allows a
user to specify a program that sshuttle should run. There may also be
additional issues that we have not identified.
By removing the --sudoers option (and the associated sudoers-add
script), this reduces the problems above. This code keeps the
--sudoers-no-modify feature which prints a configuration to stdout for
the user to install. It includes a clear warning about how --ssh-cmd
could potentially be abused to run other programs.
A warning about some of these issues has been in sshuttle since
version 1.1.0. This commit also adds that warning to more locations in
the documentation.
|
|
|
|
The comments at the end of issue #673 shows an example where sshuttle
exits with an OSError exception when it cannot bind to an IPv6
address. This patch makes a suggestion to try the --disable-ipv6
option instead of the cryptic error message.
|
|
Commit d6f75fa unintentionally changed the order of some of the
parameters when running the firewall process. This prevented the
--sudoers option from working properly. This patch restores the
previous ordering.
Most discussion was in issue #724. Also fixes #722 and #723.
|
|
Allow use of sudo or doas.
|
|
Fix sshuttle when using sudo's use_pty option.
|
|
Fix defunct process after flushing DNS cache.
|
|
|
|
If we run sudo with the use_pty option, the firewall process is
started in a new pseudoterminal. Other processes that are still
printing to the terminal (i.e., the main sshuttle client process,
messages from the shuttle server) have their output incorreclty
displayed. A newline character simply moves the output to the next
line without returning the cursor to the beginning of the line. Simply
changing all print commands to use \r\n line endings fixes the problem
and does not appear to cause any trouble in other configurations.
|
|
We previously called setsid() to ensure that the SIGINT generated by
Ctrl+C went to the main sshuttle process instead of the firewall
process. With the previous commit, we gracefully shutdown if either
the sshuttle process or firewall process receives a SIGINT. Therefore,
the setsid() call is optional. We still try calling setsid() since the
preferred shutdown process involves having the signal go to the main
sshuttle process. However, setsid() will fail if the firewall process
is started with sudo and sudo is configured with the use_pty option.
|
|
Typically sshuttle exits by having the main sshuttle client process
terminated. This closes file descriptors which the firewall process
then sees and uses as a cue to cleanup the firewall rules. The
firewall process ignored SIGINT/SIGTERM signals and used setsid() to
prevent Ctrl+C from sending signals to the firewall process.
This patch makes the firewall process accept SIGINT/SIGTERM signals
and then in turn sends a SIGINT signal to the main sshuttle client
process which then triggers a regular shutdown as described above.
This allows a user to manually send a SIGINT/SIGTERM to either
sshuttle process and have it exit gracefully. It also is needed if
setsid() fails (known to occur if sudo's use_pty option is used) and
then the Ctrl+C SIGINT signal goes to the firewall process.
The PID of the sshuttle client process is sent to the firewall
process. Using os.getppid() in the firewall process doesn't correctly
return the sshuttle client PID.
|
|
When we flush the DNS cache by calling resolvectl, we should wait for
the process to finish. This ensures that the cache is actually flushed
and prevents the process from showing up as defunct when processes are
listed.
|
|
When the tproxy method is used, sshuttle must be run as root:
https://sshuttle.readthedocs.io/en/stable/tproxy.html
Prior to this patch, sshuttle would encounter a exception and print a
message about how a setsockopt() call had a "PermissionError: [Errno 1]
Operation not permitted."
With this patch, we catch this exception, print a more understandable
error message, and exit.
The lack of error message clarity caused at least one bug report: #136
|
|
This is an alternative solution to pull request #611.
Previously, sshuttle would use doas on OpenBSD and sudo on Linux.
However, some Linux distributions are opting to use doas.
This patch changes the logic so that there can be multiple attempts to
elevate privilages. If the first command fails to run, it moves on to
the next command. Part of the existing code looked like it might be
attempting to do this, but it didn't work.
It also looks for the presence of doas and sudo in the path. If we can
find doas (but cannot find sudo) or if the platform is OpenBSD, we try
doas first. Otherwise, we try sudo, then doas. We try all the options
until one succeeds (including running the command without sudo or
doas) regardless of what is in the path. I'm open to adjusting
the logic here based on feedback.
If systems have both sudo and doas, they might be configured to give
different users different permissions. For example, if a user wishes
to use doas on this system, sshuttle would try sudo first and the user
would need to enter invalid passwords to eventually cause sudo to fail
and cause sshuttle to then try doas. This might not be ideal, but it
avoids implement another sshuttle argument that the user would need to
specify. Perhaps machines actually using doas will not have sudo
installed?
|
|
|
|
|
|
from the ipfw method.
|
|
|
|
|
|
|
|
is unhappy with "ValueError: too many values to unpack (expected 4)"
|
|
|
|
socket.recvmsg has been in Python since version 3.3 and we don't
support anything older then 3.6 the server side.
|
|
|
|
|
