mirror of
https://github.com/sshuttle/sshuttle.git
synced 2024-11-21 23:43:18 +01:00
5719d424de
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.
94 lines
3.6 KiB
ReStructuredText
94 lines
3.6 KiB
ReStructuredText
Usage
|
|
=====
|
|
|
|
.. note::
|
|
|
|
For information on usage with Windows, see the :doc:`windows` section.
|
|
For information on using the TProxy method, see the :doc:`tproxy` section.
|
|
|
|
Forward all traffic::
|
|
|
|
sshuttle -r username@sshserver 0.0.0.0/0
|
|
|
|
- Use the :option:`sshuttle -r` parameter to specify a remote server.
|
|
One some systems, you may also need to use the :option:`sshuttle -x`
|
|
parameter to exclude sshserver or sshserver:22 so that your local
|
|
machine can communicate directly to sshserver without it being
|
|
redirected by sshuttle.
|
|
|
|
- By default sshuttle will automatically choose a method to use. Override with
|
|
the :option:`sshuttle --method` parameter.
|
|
|
|
- There is a shortcut for 0.0.0.0/0 for those that value
|
|
their wrists::
|
|
|
|
sshuttle -r username@sshserver 0/0
|
|
|
|
|
|
- For 'My VPN broke and need a temporary solution FAST to access local IPv4 addresses'::
|
|
|
|
sshuttle --dns -NHr username@sshserver 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
|
|
|
|
If you would also like your DNS queries to be proxied
|
|
through the DNS server of the server you are connect to::
|
|
|
|
sshuttle --dns -r username@sshserver 0/0
|
|
|
|
The above is probably what you want to use to prevent
|
|
local network attacks such as Firesheep and friends.
|
|
See the documentation for the :option:`sshuttle --dns` parameter.
|
|
|
|
(You may be prompted for one or more passwords; first, the local password to
|
|
become root using sudo, and then the remote ssh password. Or you might have
|
|
sudo and ssh set up to not require passwords, in which case you won't be
|
|
prompted at all.)
|
|
|
|
|
|
Usage Notes
|
|
-----------
|
|
That's it! Now your local machine can access the remote network as if you
|
|
were right there. And if your "client" machine is a router, everyone on
|
|
your local network can make connections to your remote network.
|
|
|
|
You don't need to install sshuttle on the remote server;
|
|
the remote server just needs to have python available.
|
|
sshuttle will automatically upload and run its source code
|
|
to the remote python interpreter.
|
|
|
|
This creates a transparent proxy server on your local machine for all IP
|
|
addresses that match 0.0.0.0/0. (You can use more specific IP addresses if
|
|
you want; use any number of IP addresses or subnets to change which
|
|
addresses get proxied. Using 0.0.0.0/0 proxies *everything*, which is
|
|
interesting if you don't trust the people on your local network.)
|
|
|
|
Any TCP session you initiate to one of the proxied IP addresses will be
|
|
captured by sshuttle and sent over an ssh session to the remote copy of
|
|
sshuttle, which will then regenerate the connection on that end, and funnel
|
|
the data back and forth through ssh.
|
|
|
|
Fun, right? A poor man's instant VPN, and you don't even have to have
|
|
admin access on the server.
|
|
|
|
Sudoers File
|
|
------------
|
|
|
|
sshuttle can generate a sudoers.d file for Linux and MacOS. This
|
|
allows one or more users to run sshuttle without entering the
|
|
local sudo password. **WARNING:** This option is *insecure*
|
|
because, with some cleverness, it also allows these users to run any
|
|
command (via the --ssh-cmd option) as root without a password.
|
|
|
|
To print a sudo configuration file and see a suggested way to install it, run::
|
|
|
|
sshuttle --sudoers-no-modify
|
|
|
|
A custom user or group can be set with the
|
|
:option:`sshuttle --sudoers-no-modify --sudoers-user {user_descriptor}`
|
|
option. Valid values for this vary based on how your system is configured.
|
|
Values such as usernames, groups pre-pended with `%` and sudoers user
|
|
aliases will work. See the sudoers manual for more information on valid
|
|
user specif actions. The option must be used with `--sudoers-no-modify`::
|
|
|
|
sshuttle --sudoers-no-modify --sudoers-user mike
|
|
sshuttle --sudoers-no-modify --sudoers-user %sudo
|