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.
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 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.
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.
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.
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
Update docs to indicate that IPv6 is supported with the nft method.
- Adds nft into the requirements.rst file.
- Update description of what happens when a hostname is used in a
subnet.
- Add ipfw to list of methods.
- Indicate that --auto-nets does not work with IPv6. Previously this
was only mentioned in tproxy.rst
- Clarify that we try to use "python3" on the server before trying
"python".
* added sudoers options to command line arguments
* added sudoers options to command line arguments
* template for sudoers file
* Added option for GUI sudo
* added support for GUI sudo
* script for auto adding sudo file
* sudoers auto add works and validates
* small change
* Clean up for CI
* removed code that belongs in another PR
* added path for package bins
* added sudoers bin
* added sudoers-add to setup file
* fixed issue with sudoers bash script
* auto sudoers now works
* added --sudoers-no-modify option
* bin now works with ./run
* removed debug print
* Updated sudoers-add script
* Fixed error passing sudoers config to script
* more dynamic building of sudoers file
* added option to specify sudoers.d file name
* fixed indent issue
* fixed indent issue
* indent issue
* clean up
* formating
* docs
* fix for flags
* Update usage.rst
* removed shell=true
* cleared CI errors
* cleared CI errors
* removed random
* cleared linter issue
* cleared linter issue
* cleared linter issue
* updated sudoers-add script
* safer temp file
* moved bin directory
* moved bin directory
* removed print
* fixed spacing issue
* sudoers commands must only containe upper case latters
This commit resolves#297, allowing the buffers used in the latency control to be changed with a command line option ‘--latency-buffer-size’.
We do this by changing a module variable in ssnet.py (similar to the MAX_CHANNEL variable) which seems to be the simplest code change without extensive hacking.
Documentation is also updated.
--ns-hosts is available since commit d2ee34d71c
("dns: Added --ns-hosts to tunnel only some requests")
(released as v0.72), but was never documented.
--to-ns is available since commit be559fc78b
("Fix case where there is no --dns.") after several
bugfixes, released as v0.78.4, but was never
documented.
* Adds support for tunneling specific port ranges
This set of changes implements the ability of specifying a port or port
range for an IP or subnet to only tunnel those ports for that subnet.
Also supports excluding a port or port range for a given IP or subnet.
When, for a given subnet, there are intercepting ranges being added and
excluded, the most specific, i.e., smaller range, takes precedence. In
case of a tie the exclusion wins.
For different subnets, the most specific, i.e., largest swidth, takes
precedence independent of any eventual port ranges.
Examples:
Tunnels all traffic to the 188.0.0.0/8 subnet except those to port 443.
```
sshuttle -r <server> 188.0.0.0/8 -x 188.0.0.0/8:443
```
Only tunnels traffic to port 80 of the 188.0.0.0/8 subnet.
```
sshuttle -r <server> 188.0.0.0/8:80
```
Tunnels traffic to the 188.0.0.0/8 subnet and the port range that goes
from 80 to 89.
```
sshuttle -r <server> 188.0.0.0/8:80-89 -x 188.0.0.0/8:80-90
```
* Allow subnets to be specified with domain names
Simplifies the implementation of address parsing by using
socket.getaddrinfo(), which can handle domain resolution, IPv4 and IPv6
addresses. This was proposed and mostly implemented by @DavidBuchanan314
in #146.
Signed-off-by: David Buchanan <DavidBuchanan314@users.noreply.github.com>
Signed-off-by: João Vieira <vieira@yubo.be>
* Also use getaddrinfo for parsing listen addr:port
* Fixes tests for tunneling a port range
* Updates documentation to include port/port range
Adds some examples with subnet:port and subnet:port-port.
Also clarifies the versions of Python supported on the server while
maintaining the recommendation for Python 2.7, 3.5 or later.
Mentions support for pfSense.
* In Py2 only named arguments may follow *expression
Fixes issue in Python 2.7 where *expression may only be followed by
named arguments.
* Use right regex to extract ip4/6, mask and ports
* Tests for parse_subnetport
