If sudo's use_pty is enabled, the setsid() call in firewall.py will
fail (see #664). When I ignore the error, sshuttle does not behave
properly. This patch explains to the user what is happening and
suggests a workaround.
It might be possible to make sshuttle work with use_pty in the future.
Previously, we printed the server's python version in server.py.
Moving it to assembler.py means that it can be printed earlier so that
it can be seen before a potential error that could occur during
assembly. Additionally, the path to the python executable used by the
server was added to the output as well.
An example of where this would be useful: #666
Previously, it was possible to run sshuttle locally without using ssh
and connecting to a remote server. In this configuration, traffic was
redirected to the sshuttle server running on the localhost. However,
the firewall needed to distinguish between traffic leaving the
sshuttle server and traffic that originated from the machine that
still needed to be routed through the sshuttle server. The TTL of the
packets leaving the sshuttle server were manipulated to indicate to
the firewall what should happen. The TTL was adjusted for all packets
leaving the sshuttle server (even if it wasn't necessary because the
server and client were running on different machines).
Changing the TTL caused trouble and some machines, and
the --ttl option was added as a workaround to change how the TTL was
set for traffic leaving sshuttle. All of this added complexity to the
code for a feature (running the server on localhost) that is likely
only used for testing and rarely used by others.
This commit updates the associated documentation, but doesn't fully
fix the ipfw method since I am unable to test that.
This change will also make sshuttle fail to work if -r is used to
specify a localhost. Pull request #610 partially addresses that issue.
For example, see: #240, #490, #660, #606.
If pfctl returns non-zero when setting up the firewall, sshuttle exits
and indicates the exit status code. This patch makes it so the output
of pfctl is also printed so the user can get a better idea of what
caused the problem.
For example: issue #491
If an exception occurs in hostwatch, sshuttle exits. Problems
read/writing the ~/.sshuttle.hosts cache file on the remote machine
would therefore cause sshuttle to exit. With this patch, we simply
continue running without writing/reading the cache file in the remote
home directory. This serves as an alternate fix for
pull request #322 which proposed storing the cache file elsewhere.
A list of included changes:
- If we can't read or write the host cache file on the server,
continue running. Hosts can be collected through the netstat,
/etc/hosts, etc and the information can be reconstructed each run if
a cache file isn't available to read. We write a log() message when
this occurs.
- Add additional types of exceptions to handle.
- Continue even if we cannot read /etc/hosts on the server.
- Update man page to mention the cache file on the remote host.
- Indicate that messages are related to remote host instead of local
host.
- Add comments and descriptions to the code.
The output in the examples provided in the man page hadn't been
updated as sshuttle changed its output over time.
The example of testing sshuttle without a remote host was removed. It
was the first example previously and it is something that is unlikely
users will wish to do.
Also:
- Update some --help messages.
- Manpage: Fix a typo.
- Manpage: Mention that host specified with -r can be an ssh alias.
- Eliminate variable only used once.
11 years ago in commit 384d0e7c1d,
hostwatch was updated to use netstat to find hosts, and
_check_smb()/_check_nmb() were edited to immediately return. This
patch removes all of the unused code in these two functions.
Even when --tmark was used, the iptables code always used '1' for the
mark. This patch corrects the problem.
Previously, it wasn't clear if the tmark should be supplied in
hexadecimal or as an integer. This makes it use hexadecimal, checks
that the input is hexadecimal, and updates the associated
documentation.
This patch also makes --ttl information get passed to the firewall in
a way that matches how other information gets passed. The ttl and
tmark information are passed next to each other in many places and
this patch also makes the order consistent.
If the user specifies --to-ns (tells the remote server which DNS
server to use for lookups coming from sshuttle), then either --ns-host
or --dns need to also be used (route DNS requests through sshuttle).
A previous commit incorrectly made it so --to-ns and --ns-host
couldn't be successfully used together.
Attempts to fix#641.
Issue #631 suggests that we should warn about users who add sshuttle
to sudoers because it isn't obvious that when a user can run sshuttle
as root, they can run any command as root using sshuttle's -e or
--ssh-cmd parameters.
This patch adds a comment that warns about this problem to the sudoers
file. It also prints the warning to the console if the user uses an
option that writes the data directly to the file. This patch also
causes the output of the sudoers-add command to be printed to the
console so that the user can see the name of the file that was
created.
There is room for improvement: Warnings could be added to the
documentation and/or these parameters could be removed entirely.
It is possible for DNS requests to go through systemd's DNS resolution
system (which includes a cache) before sshuttle has an opportunity to
intercept the requests. The DNS entries in the cache may become
outdated when sshuttle starts or exits. This patch fixes the problem
by flushing the cache when sshuttle firewall starts and exits.
