Not written by me.

One of the coolest things about having a seedbox is that you can use its ip address as a proxy to protect your online identity and have a measure of privacy. You can create a SOCKS proxy by setting up an ssh tunnel. Its also an alternative in case that your provider doesn't offer vpn service or as many VPNs require special client software on your machine, which you may not have rights to install.

A secure shell (ssh tunnel) consists of an encrypted tunnel created through an ssh protocol connection. Users may set up ssh tunnels to transfer unencrypted traffic over a network through an encrypted channel. To set up an ssh tunnel, one configures an ssh client to forward a specified local port to a port on the remote machine. Once the ssh tunnel has been established, the user can connect to a specified local port to access the network service.

The local port doesn't need to have the same port number as the remote port. SSH tunnels provided a means to bypass firewalls that prohibit certain internet services - so long as the site allows outgoing connections. If users can connect to an external ssh server, they can create an ssh tunnel to forward a given port on their local machine to port 80 on a remote web-server. To access the remote web-server, users would point their browser to the local port at http://localhost/.

Some SSH clients support dynamic port forwarding that allows the user to create a SOCKS 4/5 proxy. In this case users can configure their applications to use their local SOCKS proxy server. This gives more flexibility than creating an SSH tunnel to a single port as previously described. SOCKS can free the user from the limitations of connecting only to a predefined remote port and server. If an application doesn't support SOCKS, a proxifier can be used to redirect the application to the local SOCKS proxy server. Some proxifiers, such as Proxycap, support SSH directly, thus avoiding the need for an SSH client.

A SOCKS proxy is basically an SSH tunnel in which specific applications forward their traffic down the tunnel to the server, and then on the server end, the proxy forwards the traffic out to the general Internet. Unlike a VPN, a SOCKS proxy has to be configured on an app by app basis on the client machine, but can be set up without any specialty client agents.

The SSH client that I will be using in this tutorial is Putty which is open-source and reputable. You can carry the portable Putty build and portable web browser in a usb flash drive!. Also will try using it with Firefox browser.

Thanks to Etel & Michael for the Mac OS X & Linux info.

Prerequisites:

PuTTY

http://portableapps.com/apps/internet/putty_portable
http://www.chiark.greenend.org.uk/~s.../download.html

If you haven't installed it yet, download PuTTY and save it where you like. PuTTY doesn't require admin rights to install; just download the .exe and run it.

Firefox

https://www.mozilla.org/en-US/firefox/all/

Setting Up the Tunnel on Windows:

Open PuTTy

O7ZGgZJ.jpg

On the left side of the GUI is the tree directory. On the right side, are the host, port number, user profile boxes. You can click on save button to save a profile configuration and the load button to load it after start-up.

Type the ip address of your seedbox such as 82.xx.xx.x or your username.your-seedbox-ip-address.com. Next, type the ssh/sftp port number in the port number box. 22 is the default port number but you can use another port number if you have a dedi box or if you're lucking enough to have a back up port number from your provider!

Note: To find the ip address of your seedbox/server, in ssh shell, type the command hostname -i . Some providers display the ip address in the client dashboard when you log in to your seedbox website (not your torrent client web-ui).

vPsZ2UW.jpg

On the left, navigate to: Connection > SSH > Tunnels.

ZKnfKBu.jpg

This is the most critical part for setting up correctly your ssh tunnel. Type your seedbox ssh/sftp port number in the port number box, better between 1025-65536. Below the port number box, type in your seedbox ip address in the form xx.xxx.xxx.x in the destination box. You can skipt the destination field by the way.

Below the destination box are the radio buttons. Select the AUTO and DYNAMIC buttons.

Now click on the ADD button. Above the ADD button, in the bigger box, you will see something D22 or Dxx which is the port number that you chose. Pressing the ADD button configures the all of the settings from the steps above.

8POSO2i.jpg

Optionally, under the Connections tree, you can browse a little bit above Tunnels to Data. Under Data, you can type in your seedbox login username in the Auto-login box. This feature will auto-log in your username (saving your from typing in your username) when you login to your seedbox from the shell (Putty).

Now its time to save your settings or you will have to redo everything all over again if you forget to do so.

In the tree directory, browse all the way back to Session (just like in the beginning). In the session box, type a name for your profile and click on the save button. I wouldn't save it under the Default Settings profile name because you may need to revert back to the default settings in case something happens. Save it once more time and make sure that your settings are saved.

Just load the default settings and then load your profile name and check that your settings are there. Especially the settings under Tunnels.


O7ZGgZJ.jpg

A few things need to happen in order for your ssh tunnel to work. You have to login to your seedbox in the ssh client (Putty). Putty has to be on. Closing the ssh client will terminate your ssh tunnel session. If Putty starts acting weird (like every other software), close it and login again. Remember that you need to configure the proxy settings in the application that you want to use with your ssh tunnel such as Firefox or Chrome. You can minimize the PuTTY window now, but don't close it. Your SSH connection should be open.

Using a SecureCRT:

At times the need arises to access a number of devices that reside in a remote network behind a single gateway server. One solution would be to establish an SSH connection to the gateway server, and then issue another SSH connection from that server to each of the devices via the remote shell. This can be problematic and time-consuming, especially if more than two jumps are required. Fortunately, there is a better way: dynamic port forwarding.

SecureCRT provides the ability to create an SSH connection with a dynamic port forwarding configuration that can then be used as a SOCKS proxy to reach all machines within a remote network (behind the gateway). Using an SSH SOCKS proxy, any application that is SOCKS 4 or 5 compatible (including other sessions established with SecureCRT) will be able to have their connections forwarded through this SSH SOCKS proxy and on to the desired destination.

This tip focuses on using SecureCRT's dynamic port forwarding functionality with a "Master" session to create an SSH SOCKS proxy associated with a connection to a gateway server. Additional SecureCRT sessions can then connect through the "Master" session's SSH SOCKS proxy to remote servers that are located behind the gateway server. The graphic below illustrates this concept:


7xviIjX.jpg

Configuring the "Master Session" to the Gateway Server

The first step is to configure a "Master" session that can successfully connect via the SSH protocol to the gateway server (also known as a "jump host"). This "Master" session will then need to be modified to have a dynamic port forward configuration. A dynamic port forward is a listening port which acts as a SOCKS proxy that is automatically created when the “Master” session is used to connect to the gateway server. Note that the term “gateway server” used here refers to any SSH server that supports port forwarding functionality.

The configuration of a dynamic port forward is accomplished using the following steps:

1. Set up an SSH session to the gateway server in SecureCRT.

- Make sure you set the Hostname field to match the hostname of your gateway SSH server.
- Name this session "Master" session (you can choose another name, but "Master" is used in this documentation as an example).
- Test your "Master" session to ensure that you can successfully connect and authenticate to the gateway SSH server.

Unable to add more images

http://i.imgur.com/db7f9i9.jpg

2. Modify your "Master" session to have a dynamic port forwarding configuration.

- Open the Session Options dialog for your "Master" session.
- Select the Connection / Port Forwarding category, and then press the Add button.
- In the Name field, specify a unique description. For example, SSH SOCKS Proxy.
- Enter a value for the Local / Port field by entering a listening port value. Since this port forward will be used as a SOCKS proxy, it makes sense to specify 1080 (the standard SOCKS port).
- Enable the Dynamic forwarding using SOCKS 4 or 5 option (the other fields in the Remote category will not be used in this configuration).

http://i.imgur.com/HpoSvhn.jpg

- Since this "Master" session will need to be connected and remain connected for all sessions that use the SSH SOCKS proxy, it would also be a good idea to make the following configuration changes to the "Master" session (both options are found in the main Terminal category of the Session Options dialog as depicted below):

i. Enable the Send Protocol NO-OP option and specify an interval less than the idle timeout of the remote server or remote shell.
ii. Enable the Auto reconnect option so that if the connection goes down unexpectedly, SecureCRT will automatically attempt to re-establish the connection.

http://i.imgur.com/UMEhiAb.jpg

Configuring a Global Firewall/Proxy Setup in SecureCRT

Now that the dynamic port forward is set up in the "Master" session, a global firewall configuration will need to be created so that other SecureCRT sessions can use the SSH SOCKS proxy. To set up a global firewall/proxy in SecureCRT:

1. Open SecureCRT's Global Options dialog and select the Firewall category.

2. Press the Add button and use the following configuration guidelines.

- Specify a Name for the firewall (for example: Gateway Firewall).
- Set the Type field to SOCKS version 5 (no authentication).
- In the Hostname or IP field, type: 127.0.0.1.
- Set the Port field to match what your "Master" session's dynamic port forward setup is configured to listen on (1080 as per previous example).

http://i.imgur.com/hToPMma.jpg

3. After pressing the OK button on the Firewall Properties dialog, the new firewall configuration should appear in the Firewalls list within the Firewall category of the Global Options dialog, and can be used within other SecureCRT session configurations as well as from the Quick Connect window.

Configure a SecureCRT "Client" Session to Connect Through the SSH SOCKS Proxy

With a firewall/proxy configured as explained in the section above, the Session Options dialog for a new or existing session should provide the new firewall (named "Gateway Firewall" in the example) in the category that matches the protocol being used. To elaborate, any session that is configured to connect to the machines behind the gateway server can use this firewall as the Firewall setting in the connection configuration options, as illustrated below:

http://i.imgur.com/joVnjZT.jpg

When connecting through an SSH SOCKS proxy, host name resolution occurs on the SSH gateway server. Therefore, you would specify the Hostname as it is known by the gateway server, which will be making the connection to the host on behalf of SecureCRT.

Putting Everything Together

Once "Master" and "Client" sessions have been created as described above, the process of connecting to a machine behind the gateway through the SSH SOCKS proxy is fairly simple:

1. Connect to the gateway machine using the "Master" session. In order to connect to machines in the gateway server's LAN, the "Master" session must first be connected successfully.

2. Tip for Windows users: Some users may want to set up a shortcut in their Windows profile Startup folder to launch SecureCRT with the "Master" session to allow for the "Master" session to be up and running as soon as they log on to their Windows system. The shortcut's Run property can be set to Minimized to ensure that the SecureCRT application is started in a minimized state.

3. Connect to machines located within the gateway server's LAN. In the example session configuration described earlier, a session was created and saved with a configuration instructing SecureCRT to use the SSH SOCKS proxy provided by the "Master" session.

However, using a saved session isn't a requirement. It's just as easy to bring up the Quick Connect dialog, specify the remote host name, and select the SSH SOCKS firewall/proxy configuration as the firewall to use (see the graphic below). With a press of the Connect button, a connection through the SSH SOCKS proxy will be initiated.

http://i.imgur.com/leS6aol.jpg

Taking it a Step Further: SSH SOCKS Proxy "Chaining"

http://i.imgur.com/roQxgNU.jpg

Once you have a "Master" session in place that gets you to your first gateway machine and sets up the first layer's SSH SOCKS proxy, follow these general steps to "chain" a secondary SSH SOCKS proxy through a primary SSH SOCKS proxy:

1. Create a "Secondary Master" session that connects to the secondary gateway machine through the SSH SOCKS proxy that is provided by the "Master" session. For example:

- Set the Hostname field to match the name of the secondary gateway machine (Gateway B in the picture).
- Configure the Firewall field to match the name of the firewall you created earlier (Gateway Firewall) so that the "Secondary Master" session connects through the "Master" session's SSH SOCKS proxy.
- Configure the "Secondary Master" session's Port Forwarding category with a dynamic forward that listens on a port that is different than the "Master" session's SSH SOCKS proxy. In our earlier example, the "Master" session's dynamic forward SOCKS Proxy was configured to listen on the default SOCKS port, 1080. Your "Secondary Master" session must listen on a different port since port 1080 is already bound to the "Master" session's SSH SOCKS proxy listening port. As one example, you could use port 11080.

2. Create a new firewall configuration in the Global Options dialog in similar fashion as is described in our earlier example (See the "Configuring a Global Firewall/Proxy Setup in SecureCRT" above), with the major differences being the name of the firewall (i.e., "Secondary Gateway Firewall") and the port (port should match the one you chose in step 1c immediately above).

Once you have the "Secondary Master" session and corresponding firewall defined within SecureCRT's global options, you can connect to a third-tier machine behind the second gateway machine using these steps:

1. Connect to the "Master" session (if not already connected).
2. Connect to the "Secondary Master" session (if not already connected).
3. Connect to the actual host name of the third-tier machine (Server C in the picture), using the global firewall definition (named “Secondary Gateway Firewall”) that corresponds to the "Secondary Master" session's dynamic port forward.

Setting Up the Tunnel on Mac OS X/Linux:

On your local computer, create an SSH key. If you already have an SSH key, you can use that one.

How To Set Up SSH Keys:

About SSH Keys

SSH keys provide a more secure way of logging into a virtual private server with SSH than using a password alone. While a password can eventually be cracked with a brute force attack, SSH keys are nearly impossible to decipher by brute force alone. Generating a key pair provides you with two long string of characters: a public and a private key. You can place the public key on any server, and then unlock it by connecting to it with a client that already has the private key. When the two match up, the system unlocks without the need for a password. You can increase security even more by protecting the private key with a passphrase.
Step One—Create the RSA Key Pair

The first step is to create the key pair on the client machine (there is a good chance that this will just be your computer):

ssh-keygen -t rsa

Step Two—Store the Keys and Passphrase

Once you have entered the Gen Key command, you will get a few more questions:

Enter file in which to save the key (/home/demo/.ssh/id_rsa):

You can press enter here, saving the file to the user home (in this case, my example user is called demo).

Enter passphrase (empty for no passphrase):

It's up to you whether you want to use a passphrase. Entering a passphrase does have its benefits: the security of a key, no matter how encrypted, still depends on the fact that it is not visible to anyone else. Should a passphrase-protected private key fall into an unauthorized users possession, they will be unable to log in to its associated accounts until they figure out the passphrase, buying the hacked user some extra time. The only downside, of course, to having a passphrase, is then having to type it in each time you use the Key Pair.

The entire key generation process looks like this:

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/demo/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/demo/.ssh/id_rsa.
Your public key has been saved in /home/demo/.ssh/id_rsa.pub.
The key fingerprint is:
4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 demo@a
The key's randomart image is:
+--[ RSA 2048]----+
| .oo. |
| . o.E |
| + . o |
| . = = . |
| = S = . |
| o + = + |
| . o + o . |
| . o |
| |
+-----------------+

The public key is now located in /home/demo/.ssh/id_rsa.pub The private key (identification) is now located in /home/demo/.ssh/id_rsa

Step Three—Copy the Public Key

Once the key pair is generated, it's time to place the public key on the virtual server that we want to use.

You can copy the public key into the new machine's authorized_keys file with the ssh-copy-id command. Make sure to replace the example username and IP address below.

ssh-copy-id user@123.45.56.78

Alternatively, you can paste in the keys using SSH:

cat ~/.ssh/id_rsa.pub | ssh user@123.45.56.78 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

No matter which command you chose, you should see something like:

The authenticity of host '12.34.56.78 (12.34.56.78)' can't be established.
RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '12.34.56.78' (RSA) to the list of known hosts.
user@12.34.56.78's password:
Now try logging into the machine, with "ssh 'user@12.34.56.78'", and check in:

~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Now you can go ahead and log into user@12.34.56.78 and you will not be prompted for a password. However, if you set a passphrase, you will be asked to enter the passphrase at that time (and whenever else you log in in the future).

Optional Step Four—Disable the Password for Root Login

Once you have copied your SSH keys unto your server and ensured that you can log in with the SSH keys alone, you can go ahead and restrict the root login to only be permitted via SSH keys.

In order to do this, open up the SSH config file:

sudo nano /etc/ssh/sshd_config

Within that file, find the line that includes "PermitRootLogin" and modify it to ensure that users can only connect with their SSH key:

PermitRootLogin without-password

Put the changes into effect:

reload ssh

Though it’s good practice to give your SSH key a passphrase, for this tutorial we will actually leave the passphrase blank to avoid issues later on.

As you set up the key, make sure you add it to the authorized keys for the sudo user on the server (in this example, that's the sammy user).

Open a terminal program on your computer. On Mac OS X, this is Terminal in Applications > Utilities.

Set up the tunnel with this command:

ssh -D 8123 -f -C -q -N sammy@example.com

Explanation of arguments:

D: Tells SSH that we want a SOCKS tunnel on the specified port number (you can choose a number between 1025-65536)
f: Forks the process to the background
C: Compresses the data before sending it
q: Uses quiet mode
N: Tells SSH that no command will be sent once the tunnel is up

Be sure to replace "sammy@example.com" with your own sudo user and server IP address or domain name.

Once you enter the command, you'll immediately be brought to the command prompt again with no sign of success or failure; that's normal.

Verify that the tunnel is up and running with this command:

ps aux | grep ssh

You should see a line in the output like:

sammy 14345 0.0 0.0 2462228 452 ?? Ss 6:43AM 0:00.00 ssh -D 8123 -f -C -q -N sammy@example.com

You can quit your terminal application and the tunnel will stay up. That is because we used the -f argument which put the SSH session into the background.

Setting up Your SOCKS Proxy with Firefox:

Now its time to check that your ssh tunnel is working. In Firefox, (Chrome and Safari have different proxy settings), select the Firefox orange tab, Options, and Options. Now, in the Advanced settings, select the Network tab, and Connection settings. In the Connection settings, there are five radio buttons. Select the Manual Proxy Configuration button.

All boxes need to be blank but except for the SOCKS Host and port number boxes.

In the SOCKS Host box type in 127.0.0.1 which is the local client host. Make sure that the No Proxy For box is blank. Just how it looks like in the picture above.

http://i.imgur.com/vs6Cwiy.jpg

In more details and steps:

Make sure you have the port number that you used in your SSH command or in PuTTY noted for this example. We've used 8123 in the OS X / Linux example, and 1337 in the Windows example so far, or you may have used a different port.

(The following steps were performed with Firefox version 39 but should work on other versions, though the locations of the options may be different.)

In the upper right hand corner, click on the hamburger icon to access Firefox's menu:

http://i.imgur.com/E5F2lGV.png

Click on the Preferences or Options icon. Navigate to the Advanced section. Click on the Network tab.

http://i.imgur.com/dEdxwJz.png

Click on the Settings button under the Connection heading. A new window will open. Select the radio button for Manual proxy configuration:

http://i.imgur.com/63gu5TL.png

Enter localhost or 127.0.0.1 for the SOCKS Host. Enter the same Port number from your SSH connection. In the image you can see we have entered 1337 to match the Windows instructions. Click the OK button to save and close your configuration.

Next, just browse to a website that displays your ip address. The catch is that your seedbox ip address has to display rather than your home ip address.

Optional: To verify that you are using the proxy, go back to the Network settings in Firefox. Try entering a different port number. Click OK to save the settings. Now if you try to browse the web, you should get an error message The proxy server is refusing connections. This proves that Firefox is using the proxy and not just the default connection. Revert to the correct port number, and you should be able to browse again.

Setting up Your SOCKS Proxy with Chrome:

On Windows, Chrome is using the internet explorer settings for proxy so once you apply the new settings on IE options, you can use Chrome immediately. Here is how in details,

You can go to the targeted option setting from multiple locations, I choose Chrome itself so, Run Chrome then Go to Menu → Options

http://i.imgur.com/XtbMtnN.png

Go to "Under The Hood" tab and click on "Change proxy settings"... at the "Network" section

http://i.imgur.com/m0OXglt.png


Proxy settings depends on your Operation System. Instructions for Windows:

"Choose the provider" or see below for LAN settings, and click "Settings

http://i.imgur.com/2vJjo7P.png

Click "Advanced"

http://i.imgur.com/FSQNll5.png

"Configure" your socks

http://i.imgur.com/7yC9qwn.png

If you have "only LAN", click "LAN settings"

http://i.imgur.com/A9oTPXM.png

Click "Advanced"

http://i.imgur.com/Pgui9mp.png

Configure your socks

http://i.imgur.com/7yC9qwn.png

Enjoy using socks with Google Chrome. Also there are many addons for security and anonymity available.

On any OS which has Chrome, you may use any proxy extension to apply proxy settings to chrome. Here are some

Feed proxy

https://chrome.google.com/webstore/d...pnhchfkg?hl=en

http://i.imgur.com/Tdfx94v.jpg

http://i.imgur.com/rnQvwYE.jpg

Proxy SwitchyOmega

https://chrome.google.com/webstore/d...mclgjgif?hl=en

http://i.imgur.com/y29ZNl5.jpg

Direct - is no proxy settings profile
System Proxy - is using same as system settings
Proxy - activating proxy settings which is in the next screenshot

http://i.imgur.com/ezN4JkT.jpg

Proxy Helper

https://chrome.google.com/webstore/d...bnkmbnic?hl=en

http://i.imgur.com/JR9420p.jpg

http://i.imgur.com/lgNvifd.jpg

http://i.imgur.com/KRwNnyc.jpg

FoxyProxy Standard

https://chrome.google.com/webstore/d...onogaaifnjlfnp

FoxyProxy Basic
https://chrome.google.com/webstore/d...eahomimbllocnb

On Linux, changing proxy via terminal using couple of commands. Here are what I found but NOT tested about this

I really like chrome, but something that is an absolute must is a SOCKS5 proxy putty ssh private key location. Â This is due to my ultra restrictive corporate firewall, i need to tunnel http content through an ssh tunnel putty ssh server. Â And ssh creates a SOCKS5 proxy when you use the -D option. Â Chrome seems like it assumes that your proxy is SOCKS4.x and just fails on the ssh tunnel proxy. Â But there is hope, i found a way to work around this and it isn’t even complicated!

Just a quick note, i actually use a plugin from chrome called Switchy! which helps me quickly switch to and from the ssh tunnel proxy. Â It is certainly no foxyproxy, but it works well enough that i can use it to solve most proxy related problems.

Now, the secret to this solution is to use Proxy Auto Configuration scripts. Â These scripts allow you to specify which version of SOCKS to use for your proxy. Â So all you need to do is create a file somewhere on your computer (say called pac-ssh-tunnel.pac) and then add the following to it:

function FindProxyForURL(url, host) { return "SOCKS5 localhost:8080"; }Now, take note that i am creating the ssh tunnel proxy using the following command:

ssh -N -g -D 8080 username@remote_serverJust FYI, “-N” means don’t execute any commands on the server (i.e. strictly a tunnel connection only). Â And “-g” allows the remote host to connect to locally forwarded ports (which i must admit, most people will never need this, but handy if you do complex tunneling of data). Â Finally, “-D 8080″ means dynamically forward the proxy data through local port 8080.

So once you have your SSH SOCKS5 tunnel up and running, set chrome to use your proxy automatic configuration script that you created (either through chrome’s options, or through Switchy! if you prefer). Â Now you can proxy traffic over your ssh tunnel.

One final note, PAC files are basically javascript files (with a few built-in functions). Â You can actually create some complicated PAC files that do all your complex proxy selection for you (basically a lot of regular expression matching). Â So if you get adventurous, you can just add all your proxy selection logic to that one function (or break it into multiple functions) and then you won’t even need to change your proxy around ever!

Socks5 proxies are great. They allow you to tunnel all traffic for applications that support Socks proxies through the proxy. One example I frequently use is starting a Chrome window that will do everthing as if it was an a remote machine. This is especially useful to bypass firewalls so you can test websites that are only available on localhost on a remote machine, or sites that can only be accessed if you're on a remote network. Basically it's a poor-man's application-specific VPN over SSH.

Normally I run the following:

ssh -D 8000 -N remote.example.com &
chromium-browser --temp-profile --proxy-server="socks5://localhost:8000"

However that quickly becomes tedious to type, so I wrote a script:

#!/bin/bash
HOST=$1
SITE=$2

if [ -z "$HOST" ]; then
echo "Usage; $0 <HOST> [SITE]"
exit 1
fi

while `true`;
do
PORT=$(expr 8000 + $RANDOM / 32) # random port in range 8000 - 9000
if [ \! "$(netstat -lnt | awk '$6 == "LISTEN" && $4 ~ ".$PORT"')" ]; then
# Port not in use
ssh -D $PORT -N $HOST &
PID=$!
chromium-browser --temp-profile --proxy-server="socks5://localhost:$PORT" $SITE
kill $PID
exit 0
fi
done

The script finds a random unused port in the range 8000 – 9000, starts a Socks5 proxy to it and then starts Chromium on that socks proxy.

Tunneling, Adding a Proxy to uTorrent:

The same procedure can be done through a BitTorrent client such as uTorrent. This is a great tip to bypass firewalls in your office, college or anywhere else that doesn’t appreciate torrents, for that matter.

In uTorrent, go to Options > Preferences and click on the Connection tab. Choose SOCKS5 from the dropdown in Proxy Server Type. Enter “localhost” for the proxy, and enter in your port number (ie – 52014). Also, disable (uncheck) UPnP & NAT-PMP port mapping – and while you’re at it, click on the BitTorrent tab and disable DHT, Local Peer Discovery and Peer Exchange (these can all leak your real IP address). Click Apply and OK to finish.

http://i.imgur.com/vU7eYRK.gif

To test this out, head on down to CheckMyTorrentIP.com and download a torrent & open it into uTorrent. This new torrent should detect your seedbox IP, which in our case is 217.114.222.95.

http://i.imgur.com/aGIQWux.gif

Back on CheckMyTorrentIP.com, the “Check IP” tab will show both your torrent IP and browser IP addresses – and since we’ve configured both the BT client and the browser to use our tunnel, they’re obviously the same IPs (of our seedbox)

http://i.imgur.com/NxQsNvi.gif

Other services to check your ip

http://checkmytorrentip.upcoil.com
http://ipmagnet.services.cbcdn.com
https://ipleak.net/
https://torguard.net/checkmytorrentipaddress.php
http://checkmytorrentip.net/

NOTE: This likely won’t raise any red flags on your private trackers, since this is the same principle as using a seedbox directly anyways. However, we don’t advise you to log into your private tracker accounts (or download .torrents) while using your seedbox proxy in the web browser, as this might be perceived that you’re sharing the account. If in doubt, always ask tracker staff first – explain that you’ll be logging in through the seedbox; they won’t have a problem with this as long as they know in advance.

NOTE: Using this on utorrent will likely leave the home client unable to accept incoming connections. Port forwarding seems to be required on the seedbox machine to achieve that. To solve that we will do port forwarding command via ssh. For direct example, let's say we are using the following details:

uTorrent port: 65001
seedbox host ip/domain: 55.44.22.11
seedbox ssh port: 22
seedbox username: usermore
seedbox password: passmore

To do port forwarding and allow connectivity simply enter and apply this command in the terminal ssh session you got open for tunneling

ssh -L 65001:localhost:22 -o GatewayPorts=yes usermore@55.44.22.11

It will ask for the password. To make this command permanent with the password inline, use sshpass package. Once installed sshpass package, you may use this command

sshpass -p "passmore" ssh -L 65001:localhost:22 -o GatewayPorts=yes usermore@55.44.22.11

Once that command is done, the server will ssh to itself with port forwarding in mind. There are other ways to forward ports on Linux machines but this is one of the simplest and within our ssh activity which is the topic of this post..

Proxy for mIRC:

Sure, there are better ways to set this up natively through IRSSI and have it connect to certain networks & channels, which also allows you to connect locally on a Windows machine. But for this tut, we’ll just do it through mIRC directly.

First of all, disconnect from all active networks. In mIRC, go to Tools > Options… and click on the Firewall tab (under Connect). Change the Firewall Support to “Both” & change the Protocol to “Socks5”. Enter in localhost for the Hostname, as well as the port number – click OK to save the changes.

http://i.imgur.com/bao6XRm.gif


(Re)connect to a network. Do a WHOIS check on yourself, it will now report your seedbox IP address instead of your home one.

Happy tunneling!

Reverting to normal unsecured browsing in Firefox:

When you are done needing the privacy of the SSH tunnel, go back to the Network proxy settings (Preferences > Advanced > Network > Settings) in Firefox.

Click on "Use system proxy settings" and click OK. Firefox will now browse over your normal connection settings, which are likely unsecured.

If you are done using the tunnel you'll have to terminate the tunnel as well.

If you plan on using the tunnel often you can leave it open for later use, but note that it might terminate on its own if it’s idle for too long, or if your computer goes to sleep or powers off.


Closing the Tunnel on Mac OS X/Linux:

Closing the tunnel will stop Firefox's ability to browse over the proxy.

The tunnel we created earlier on our local machine was sent to the background, so closing the terminal window you used to open the tunnel won't terminate it.

To terminate the tunnel we need to identify the process ID (PID) using the ps command, and then kill it using the kill command.

Let's search for all active ssh processes on our machine:

ps aux |grep ssh

Find the line that looks like the command you entered earlier to create the tunnel. Here's some sample output:

sammy 14345 0.0 0.0 2462228 452 ?? Ss 6:43AM 0:00.00 ssh -D 8123 -f -C -q -N sammy@example.com

From the beginning of the line, in one of the first two columns, is a 3-5 digit number. This is the PID. Above, the sample PID of 14345 is highlighted.

Now that you know what the PID is, you can use the kill command to bring the tunnel down. Use your own PID when you kill the process.

sudo kill 14345



Closing the Tunnel on Windows:

Closing the tunnel will stop Firefox's ability to browse over the proxy.

Close the PuTTY window you used to create the tunnel. That's it!

In Windows there isn't an easy way to automate the connection process, but both PuTTY and Firefox can save the settings you've previously entered, so just open the connections again to use the tunnel again.

Creating Shortcuts for Repeated Use on Mac OS X/Linux:

For OS X or Linux systems, we can make an alias or create a script to quickly create the tunnel for us. The following are two ways to automate the tunnel process.

Note: These shortcut methods both require passwordless/passphraseless SSH key authentication to the server!

Clickable BASH Script

If you want an icon to double click and the tunnel just starts, we can create a simple BASH script to do the job.

We make the script set up the tunnel and launch Firefox, although you’ll still need to add the proxy settings manually in Firefox the first time.

On OS X, the Firefox binary that we can launch from the command line is inside Firefox.app. Assuming the app is in the Applications folder, the binary will be found at /Applications/Firefox.app/Contents/MacOS/firefox.

On Linux systems, if you installed Firefox via a repo or it's pre-installed, then its location should be /usr/bin/firefox. You can always use the which firefox command to find out where it is on your system.

In the script below replace the path to Firefox with the one that is appropriate for your system.

Using a text editor like nano create a new file:

nano ~/socks5.sh

Add the following lines:

"socks5.sh" wrote:

#!/bin/bash
ssh -D 8123 -f -C -q -N sammy@example.com
/Applications/Firefox.app/Contents/MacOS/firefox &

- Replace 8123 with your desired port number (it should match what you put in Firefox)
- Replace sammy@example.com with your SSH user and hostname or IP
- Replace /Applications/Firefox.app/Contents/MacOS/firefox with the path to Firefox's binary

Save your script. For nano, type CONTROL + o, and then to quit, type CONTROL + x.

Make the script executable, so that when you double click on it, it will execute. From the command line, enter this command to add execute permissions, using your own script path:

chmod +x /path/to/socks5.sh

On OS X, you may have to perform an additional step to tell Mac OS X that a .sh file should be executed like a program and not be opened in an editor.

To do this, right click on your socks5.sh file and select Get Info.

Locate the section Open with: and if the disclosure triangle isn’t pointing down, click on it so you can see the dropdown menu. Xcode might be set as the default app.

http://i.imgur.com/FJOEqcq.png

Change it to Terminal.app. If Terminal.app isn’t listed, choose Other, and then navigate to Applications > Utilities > Terminal.app.

To open your SOCKS proxy now, just double click on the socks.sh file.

After executing, the script won’t prompt for a password, and so it will silently fail if you previously set up your SSH key to require a passphrase.

The script will open a terminal window, start the SSH connection, and launch Firefox. Feel free to close the terminal window. As long as you kept the proxy settings in Firefox, you can start browsing over your secure connection.

Not written by you and stolen from a staffer on alpha ratio and reproduced without permission.

Originally Posted by BlindFury

Not written by you and stolen from a staffer on alpha ratio and reproduced without permission.

It's written in bold at the top that i didn't write it.

Originally Posted by BlindFury

Not written by you and stolen from a staffer on alpha ratio and reproduced without permission.

When trackers will get permission for stealing and sharing copyrighted material we will get permission for sharing their tutorials and their invites

btw keep in mind that those guys might end up in jail for what they do. I don't think Ronin21 will end up in jail though