Tunnels/Connecting to SSH before Tor/Testing
From Whonix
< Tunnels | Connecting to SSH before Tor
Note: This Page is for Testing Only![edit]
Please use the stable Connecting to a SSH before Tor Wiki page for SSH configuration.
Advertisement:
It's possible to pay for the completion of this wiki page. Send reasonable price suggestions. Get in contact.
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.
User
→ SSH
→ Tor
→ Internet
The SSH tunnel be configured on the host or inside Whonix-Gateway ™.
Introduction[edit]
It is possible to combine Tor with tunnels like VPNs, proxies and SSH. The traffic can be sent through both Tor and the second tunnel, in either order. However, this is an advanced topic and appropriate only for special cases. Adding a second connection does not automatically improve security, but it will add significant complexity. The potential positive or negative effects on anonymity are being controversially debated [archive].
The Whonix project remains technologically neutral in the anonymity discussion. The improper combination of Tor and another service may actually degrade a user's security and anonymity. One such case is using a proxy to hide Tor network traffic from your ISP.
While proxies are a type of tunnel-link they should not be thought of as a replacement for a VPN and SSH in this configuration. This is because connections to proxies are unencrypted and therefore should not be used to hide Tor use. Proxies are ok for circumvention of censorship if that has been shown to work from the users location but are unsuitable for hiding Tor due to lack of encryption.
Combinations of tunnels-links with Tor are difficult to set up and should only be attempted by advanced users. For the vast majority of Whonix users, using Tor in isolation – without a tunnel-link (VPN, proxy or SSH) – is the correct choice.
Tunnel-link before Tor use cases[edit]
User
→ tunnel-link
→ Tor
→ Internet
In this configuration network traffic will (1) enter the tunnel-link and pass through your ISP → (2) exit your tunnel-link server as encrypted Tor traffic→ (3) enter to the Tor network→ (4) exit the Tor network at a Tor exit node as normal internet traffic (encrypted or unencrypted).
Possible uses:
- You must connect to your tunnel-link to access the internet.
- Your ISP blocks Tor and Tor bridges but doesn’t block the tunnel-link.
- Fear of de-anonymizing attacks against the Tor network; belief that your tunnel-link is able to protect your identity in such case.
Warnings[edit]
Note: The following warnings are not Whonix ™ specific issues. They are general issues associated with combining Tor with tunnel-links.
Tor blocks by destination servers can usually be bypassed using simple proxies, rather than adding an additional tunnel to Tor.
In order to circumvent state-level censorship of the Tor network, Bridges or other alternative circumvention tools will probably be required. [1]
Trusting Service Providers[edit]
A tunnel service provider that knows your identity and/or location may be more willing and able to compromise your privacy than your ISP.
Failed Closed Configurations[edit]
If your software configuration doesn’t block all traffic when your tunnel-link connection suddenly disconnects, your encrypted Tor traffic will go through your ISP without warning. This is the default nature of most tunnel configurations and not an issue specific to Whonix ™.[2]
Tunnel-links can Affect Anonymity[edit]
Using any extra tunnel, for example a VPN, proxy or SSH can can negatively affect anonymity under some circumstances. [3] [4]
To explain why that is, some background information is required so you can draw conclusions and take actions to avoid this risk. See below.
Using the same Tunnel Provider in Multiple VMs at the same Time[edit]
Don't use the same tunnel provider / configuration in more than one place at the same time.
For example, do not use the same tunnel setup inside Whonix-Gateway ™ as well as inside Whonix-Workstation ™. Also do not use the same tunnel setup on the host and inside a Whonix-Gateway ™ or Whonix-Workstation ™ at the same time.
Reusing Tunnel-links[edit]
Individual tunnel-links should only be used for a single configuration and never reused in any other tunnel-link chains. Doing so could tie any anonymous identities associated with the tunnel-link to the user's ISP assigned IP address.
Example:
In tunnel-chain 1, the ISP assigned IP address is permanently linked to the tunnel-link. In tunnel-chain 2, the same tunnel-link was reused. Since the users ISP assigned IP address was previously linked to that same tunnel-link, that anonymous identity can now be linked to the user actual IP address.
- Tunnel-chain 1: (
User
→Tunnel-link
[users IP address is linked] →Tor
→Internet
)
- Tunnel-chain 2: (
User
→Tor
→Tunnel-link
[anonymous activities linked] →Internet
)
The previous example also holds true if the tunnel-link is first used with tunnel-chain 2 and then reused in tunnel-chain 1. If this were done, all anonymous activities conducted with tunnel-chain 2 would then be link with the users ISP assigned IP address.
Qubes-Whonix ™ TemplateVMs[edit]
Qubes-Whonix ™ users note:
You probably do not want to run the tunnel software from within a TemplateVM. This is because the whonix-gw-15
TemplateVM "is more like a workstation". It is behind sys-whonix
. It is not sys-whonix
itself.
(If you are using openvpn
inside Whonix-Gateway ™ (commonly called sys-whonix
) or Whonix-Workstation ™ (commonly called anon-whonix
) while following Whonix documentation, openvpn
will not start inside the whonix-gw-15
or whonix-ws-15
TemplateVM.) [5]
In Qubes R4 and above, the TemplateVMs's NetVM is purposely set to none
by Qubes default [archive]. (They are upgraded through the qrexec based updates proxy that will be running on sys-whonix
.)
Hiding Tor Usage from ISPs[edit]
If using Tor is dangerous in your area, VPNs or SSH may not provide enough protection (due to software misconfiguration or sophisticated packet inspection).
Selecting a Service Provider[edit]
Selecting a provider location presents unique challenges that must be accounted for when chaining tunnel-links with Tor.
- Tor avoids using more than one relay belonging to the same operator when building circuits. Legitimate Tor relay operators adhere to Tor's relay operator practices of announcing which relays belong to them by declaring this in the Tor relay family setting. Tor also avoids using Tor relays that are within the same network by not using relays within the same /16 subnet. [6] Tor however does not take into account your real external IP nor destination IP addresses. [7] In essence, you must avoid using the same network/operator as your first and last Tor relays since this would open up end-to-end correlation attacks.
- Many tunnel providers use shared IP addresses which means that many users share the same external IP address. On one hand this is good since that is similar to Tor, where many users share the same Tor exit relays. On the other hand, this can in some situations lead to actually making you less safe.
- It is possible to host Tor relays [any... bridges, entry, middle or exit] behind VPNs or tunnel-links. For example, there are VPN providers that support VPN port forwarding. This is an interesting way to contribute to Tor while not exposing oneself to too much legal risk. However, in certain situations it is possible a VPN or other tunnel-link and a Tor relay could be hosted by the same operator, in the same network or even on the same IP.
- In an economy with a deep labor division, there are those that provide the service to host servers (VPS etc.). While others provide VPN and other tunnel-link services and rent such servers. It is common that diverse customers run and/or share the same IP address. This is another situation where a VPN or other tunnel-link and a Tor relays could be hosted by the same operator, in the same network or even on the same IP.
- By adding arbitrary tunnel-links to your connection chain, you could unknowingly use the same operator/network twice in your connection chain.
- Scenario 1)
- a) User uses VPN IP A on the host, thereby using it as it is first relay.
- b) User's Tor client happens to pick a Tor exit relay running on VPN IP A.
- Conditions a and b match at the same time. The user is now using the same IP address as first and last proxy.
- --> By using the VPN the user did not get more, but less secure.
- Scenario 2)
- a) User sets up a VPN inside Whonix-Workstation ™. This configuration results in
User
→Tor
→VPN
→Internet
. Using VPN IP A. - b) A Tor entry guard is being hosted on VPN IP A.
- Conditions a and b match at the same time. The user is now using the same IP as first and last proxy.
- --> By using the VPN the user did not get more, but less secure.
- a) User sets up a VPN inside Whonix-Workstation ™. This configuration results in
- Scenario 1)
- Choose your tunnel providers wisely.
- Find out in which physical and legal jurisdiction and network their servers are located.
- Perhaps avoid using VPN or SSH providers that support port forwarding.
- Perhaps use only tunnel-link providers that are assigning private - as in not shared with others - unique - IP addresses. However, it is not clear if this does more harm than gain as noted above.
- Perhaps use tunnel-link providers that run their own servers rather than relying on shared infrastructure.
- Perhaps manually pick your Tor relay[s]. Specifically your entry guard[s] or bridge[s]).
- Tor documentation generally discourages tampering with Tor's routing algorithm by manually choosing your relays, but since you are trying to be clever by extending your Tor chain despite of all the information regarding the difficulty of this endeavor, perhaps it would make sense to pick your entry guard manually.
- Using Bridges might be an alternative, but note the following quote. "Bridges are less reliable and tend to have lower performance than other entry points. If you live in a uncensored area, they are not necessarily more secure than entry guards. Source: bridge vs non-bridge users anonymity [archive]."
SSH Configuration[edit]
Install SSH Client[edit]
sudo apt-get update
sudo apt-get install ssh
Test Connection[edit]
ssh yourusername@your.ssh.server
- TODO: Public key authentication steps
apt-get install lynx
lynx check.torproject.org
exit
Configure Local Server[edit]
ssh -D 1080 your.ssh.server
- TODO: Run in background on each start up before Tor.
- TODO: Public Key authentication steps
Configure Tor[edit]
Option 1: Use Anon Connection Wizard[edit]
Beginning with Whonix ™ 14, a prefixed proxy can be configured easily using Anon Connection Wizard.
Step 1: Start Anon Connection Wizard[edit]
If you are using Qubes-Whonix ™, complete the following steps.
Qubes App Launcher (blue/grey "Q")
→ Whonix-Gateway ™ ProxyVM (commonly named sys-whonix)
→ Anon Connection Wizard
If you are using a graphical Whonix-Gateway ™, complete the following steps.
Start Menu
→ Applications
→ System
→ Anon Connection Wizard
If you are using a terminal Whonix-Gateway ™, type.
lxsudo anon-connection-wizard
Step 2: Use Proxy Configuration Page[edit]
Select "Use proxy before connecting to the Tor network" on the Proxy Configuration page
→ Choose the proxy type
→ Fill out other necessary information
The proxy type is the protocol which is used to communicate with the proxy server. Since there are only three options, they can all be tried until one works.
2. Proxy IP/hostname
It is necessary to know the proxy IP for attempted connections. If the user is trying to connect to a local proxy, then 127.0.0.1 should be specified since it is the localhost.
3. Proxy Port number
It is necessary to know the port number for attempted connections. It should be a positive integer from 1 to 65535. If searching for the listening port number of a well-known censorship circumvention tool, it can be found online.
4. Username and Password If the username and password are unknown, they should be left blank to see if the connection will succeed. In most cases they are not needed.
Option 2: Manually Configure Proxy[edit]
Open /usr/local/etc/torrc.d/50_user.conf
.
If you are using Qubes-Whonix ™, complete the following steps.
Qubes App Launcher (blue/grey "Q")
→ Whonix-Gateway ™ ProxyVM (commonly named sys-whonix)
→ Tor User Config (Torrc)
If you are using a graphical Whonix-Gateway ™, complete the following steps.
Start Menu
→ Applications
→ Settings
→ /usr/local/etc/torrc.d/50_user.conf
If you are using a terminal-only Whonix-Gateway ™, complete the following steps.
sudo nano /usr/local/etc/torrc.d/50_user.conf
- If SSH tunnel was setup from Whonix-Gateway ™:
Socks5Proxy 127.0.0.1:1080
- If SSH tunnel was setup from host operating system, change IP:PORT as needed:
Socks5Proxy IP:PORT
Firewall Configuration[edit]
- TODO: if running inside Whonix-Gateway ™, new firewall rules are probably required.
Footnotes[edit]
- ↑ Users in China are unlikely to circumvent government censorship [archive] with vanilla bridges, as they are uniformly blocked. That said, anon-connection-wizard configured with the meek-amazon or meek-azure pluggable transport is reported to bypass Chinese censorship in late 2017.
- ↑ For example, VPNs require a failed closed configuration to prevent DNS leaks.
- ↑ https://lists.torproject.org/pipermail/tor-talk/2016-July/041757.html [archive]
- ↑ research / document impact for tunnel users if Tor relays hosted at the same tunnel provider [archive]
- ↑
This is because file /lib/systemd/system/openvpn@openvpn.service.d/50_unpriv.conf [archive] checks the following condition
ConditionPathExists=!/var/run/qubes-service/whonix-template
Which means, if file
/var/run/qubes-service/whonix-template
exists, which is the case in Whonix TemplateVMs, the openvpn@openvpn service will not be started. - ↑ http://tor.stackexchange.com/a/114/80 [archive]
- ↑ https://lists.torproject.org/pipermail/tor-talk/2016-July/041753.html [archive]
Whonix ™ is Supported by Evolution Host DDoS Protected VPS. Stay private and get your VPS with Bitcoin or Monero.
Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki
Want to help create awesome, up-to-date screenshots for the Whonix ™ wiki? Help is most welcome!
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation. Policy of Whonix Website and Whonix Chat and Policy On Nonfreedom Software applies.
Copyright (C) 2012 - 2020 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee [archive] of the Open Invention Network [archive]. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)
Whonix ™ is a derivative of and not affiliated with Debian [archive]. Debian is a registered trademark [archive] owned by Software in the Public Interest, Inc [archive].
Whonix ™ is produced independently from the Tor® [archive] anonymity software and carries no guarantee from The Tor Project [archive] about quality, suitability or anything else.
By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint, Contact.