Connecting to Tor before SSH

From Whonix
Jump to navigation Jump to search

Fractal-429037640.jpg

UserTorSSHInternet

Introduction[edit]

Ambox warning pn.svg.png Before combining Tor with other tunnels, be sure to read and understand the risks!

Ambox notice.png Advertisement:
Too difficult to set up? Provider specific automation can be created for you by the lead developer of Whonix ™. Send reasonable price suggestions. Get in contact.

Ambox warning pn.svg.png Documentation for this entry is incomplete. Contributions are happily considered!

Procedure[edit]

Note that even though SSH supports SOCKS5, SSH is still not able to forward UDP on its own. Read the Performing UDP tunneling through an SSH connection instructions for further details. To summarize: to tunnel UDP over SSH, the client and shell admin need a special setup, which is not going to happen for most shells:

  1. A SSH tunnel will provide a local SOCKS5 proxy.
  2. Create the SSH tunnel in the Whonix-Workstation ™; this will provide a local SOCKS5 proxy.
  3. Utilize the SOCKS5 proxy by following the Connecting to Tor before a Proxy (User → Tor → proxy → Internet) instructions.
  4. Once the SSH tunnel is established, there are not many differences except the UDP issue canvassed above and the fact the warning about missing proxy encryption does not apply to SSH tunnels (since SSH is encrypted).
  5. The SSH process needs to be allowed to access the Internet directly -- if you use transparent proxying, run the SSH process under an account which is privileged to access the Internet directly.

Another possible, untested method may be sshuttle (stable documentation). [1]

Footnotes[edit]

  1. As far as I know, sshuttle is the only program that solves the following common case:

    • Your client machine (or router) is Linux, MacOS, FreeBSD, OpenBSD or pfSense.
    • You have access to a remote network via ssh.
    • You don’t necessarily have admin access on the remote network.
    • The remote network has no VPN, or only stupid/complex VPN protocols (IPsec, PPTP, etc). Or maybe you are the admin and you just got frustrated with the awful state of VPN tools.
    • You don’t want to create an ssh port forward for every single host/port on the remote network.
    • You hate openssh’s port forwarding because it’s randomly slow and/or stupid.
    • You can’t use openssh’s PermitTunnel feature because it’s disabled by default on openssh servers; plus it does TCP-over-TCP, which has terrible performance (see below).