sshuttle has a --latency-buffer-size parameter, but it only changes
the buffer size on the client and not the server. Therefore,
increasing or decreasing the number doesn't make any change in
download performance (like the documentation indicates that it should).
You can test this change by setting up a sshuttle connection and
downloading a large file through sshuttle. With this patch, you should
find that increasing --latency-buffer-size increases the download
speed. Without the patch, the parameter should have little impact on
performance.
It used to be necessary to fix the version of attrs when using pytest. This problem has been fixed now, so I removed it.
https://stackoverflow.com/a/58198754
If you use the tproxy method with a large subnet (such as 0/0), then
(1) you may not receive UDP packets that sshuttle/tproxy can handle
and (2) you are unable to connect to your machine using an IP that
your computer recognizes as its own.
To resolve those issues, any traffic to an IP that the host knows is
local, does not go through the sshuttle chains.
* Improve error messages related to sshuttle server.
There are many GitHub issues related to the cryptic message:
fatal: expected server init string 'SSHUTTLE0001'; got b''
The code that prints that message is after another check that is
intended to verify that the server is still running. This code was
faulty since the server is still running when rv==None (but exited
when rv==0).
I corrected this problem and then investigated ways to clarify the
error message. I added additional exit codes for the server: 97 (exec
in the shell returned), 98 (the python exec() function called
returned). The end result is that the cryptic error message above will
now print a more appropriate error message that should aid in
debugging.
I also changed the server so that it catches Fatal() and exits with
exit code 99 (like the client does). Previously, it was just an
unhandled exception on the server.
I suspect some of the error messages were caused by restricted shells.
I also investigated and added comments about how sshuttle might behave
if it is being run on a server that has a restricted shell.
This commit also replaces a couple of exit() calls in cmdline.py with
'return' since exit() is intended for interactive use. This change
doesn't impact the server.
* Remind user to exclude remote host when server exits with 255.
This commit rewrites the log() function so that it will append a
newline at the end of the message if none is present. It doesn't make
sense to print a log message without a newline since the next log
message (which will write a prefix) expects to be starting at the
beginning of a line.
Although it isn't strictly necessary, this commit also removes any
newlines at the ends of messages. If I missed any, including the
newline at the end of the message will continue to work as it did
before.
Previously, some calls were missing the newline at the end even though
including it was necessary for subsequent messages to appear
correctly.
This code also cleans up some redundant prefixes. The log() method
will prepend the prefix and the different processes should set their
prefix as soon as they start.
Multiline messages are still supported (although the prefix for the
additional lines was changed to match the length of the prefix used
for the first line).
When users put parameters in a config file and pass them to sshuttle
using '@', they might copy the quotes from the command line into the
config file. This fix first ensures that we strip whitespace from the
beginning/end of each line in the config file. Then, if the line
begins and ends with a matching quote character, strip those too.
Fixes#573.
Add an "is_supported()" function to the different methods so that each
method can include whatever logic they wish to indicate if they are
supported on a particular machine. Previously, methods/__init__.py
contained all of the logic for selecting individual methods. Now, it
iterates through a list of possible options and stops on the first
method that it finds that is_supported().
Currently, the decision is made based on the presence of programs in
the PATH. In the future, things such as the platform sshuttle is
running on could be considered.
Due to message from CI:
DEPRECATION: Python 3.5 reached the end of its life on September 13th,
2020. Please upgrade your Python as Python 3.5 is no longer maintained.
pip 21.0 will drop support for Python 3.5 in January 2021. pip 21.0 will
remove support for this functionality.
The server should just read from resolv.conf to find DNS servers to
use. This restores this behavior after the previous commit changed it.
The client now reads both /etc/resolv.conf and
/run/systemd/resolve/resolv.conf. The latter is required to more
reliably intercept regular DNS requests that systemd-resolved makes.
This commit makes two fixes:
1. If an IPv6 DNS server is used, an nft rule had "ip6 protocol" in it
which is invalid and caused sshuttle to exit.
2. I modified detection of udp vs tcp to follow the recommendation at
https://superuser.com/questions/1560376/match-ipv6-protocol-using-nftables
I also re-arranged the code slightly to reduce the number of
if-statements.
Some methods are unable to determine the destination address of DNS
packets that we capture. When this happens, change the message so it
just shows where the DNS requests are from.
Previously, we would find DNS servers we wish to intercept traffic on
by reading /etc/resolv.conf. On systems using systemd-resolved,
/etc/resolv.conf points to localhost and then systemd-resolved
actually uses the DNS servers listed in
/run/systemd/resolve/resolv.conf. Many programs will route the DNS
traffic through localhost as /etc/resolv.conf indicates and sshuttle
would capture it. However, systemd-resolved also provides other
interfaces for programs to resolve hostnames besides the localhost
server in /etc/resolv.conf.
This patch adds systemd-resolved's servers into the list of DNS
servers when --dns is used.
Note that sshuttle will continue to fail to intercept any traffic sent
to port 853 for DNS over TLS (which systemd-resolved also supports).
For more info, see:
sshuttle issue #535https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.htmlhttps://github.com/systemd/systemd/issues/6076
