For some reason, Clarkson has recently found it necessary to block incoming requests to dorm subnets, making it impossible to directly access your campus-connected computer from somewhere else in the world. This is very frustrating, especially if you host services on your computer, such as Subversion, a web server or other things.
To remedy this situation, I’ve done a little reading on using SSH to forward ports from your computer to a remote computer, thus providing a pathway (encrypted, I might add) from your off campus computer to some location on campus. This is quite beneficial for a number of reasons and I’ll list some examples to help me explain.
First, I used the following SSH command the other day to download a file from the web server running on Ryan‘s computer:
ssh -D 8080 -Nf <username>@<ssh server on campus>
This accomplishes a few things. First, it creates an encrypted connection between your computer and some server on campus (obviously one that’s accessible from the world). Secondly, the -D 8080 portion creates a SOCKS v5 proxy on your local machine that forwards all requests it receives across the ssh connection. This means that if you open Firefox’s connection settings and set your SOCKS v5 proxy to localhost:8080, you can access webpages as if you were directly connected to the Clarkson network.
Second, I used this command just today to access my computer’s Subversion repositories (over http):
ssh -Nf -L8080:<remote server>:80 <username>@<ssh server on campus>
I was then able to check out code from Subversion on my campus-connected computer using svn co http://localhost:8080/svn/. Everything requested from localhost:8080 is sent over the SSH connection to the port on the remote server specified. This same idea can be applied to any ports you might need… 3389 for remote desktop, 22 for SSH, 20/21 for ftp, etc.
I should also mention the -Nf portion of each command. -N tells ssh not to execute remote commands, aka, don’t give a command prompt after connecting. The -f piece simply sends the ssh session to the background once connected. Both of these are particularly useful when using SSH to forward ports for other services.
I’m sure this is just touching on the surface of what’s possible when using the port forwarding features of SSH. These two ways of doing it have proven very useful for me and at least now they’re documented here for me to reference. Hopefully you find them helpful too.
P.S. For a limited time only, please enjoy the improperly nested blinking marquee at the top of the page! No telling when this feature will vanish, so soak it up while you still can!