Well, if you’re out and about quite a bit and you run a Linux computer at home, you should have a good relationship with SSH. If you’ve never felt the need to access your home computer remotely, this is what you should do.
For those that don’t know what SSH is, it is basically a network protocol (for example like FTP, SMTP, etc) that allows you to securely connect to another computer. For those that don’t speak jargon, it is some cool thing that allows me to use my computer remotely.
One of my well-visited locations is my college. I wonder why :P … and like most places, it runs Windows. Using a Windows computer leaves me feeling crippled and with a sense of repulsion at the most innocent of small creatures. Combined with my college’s restrictions, there is a lot of stuff I can’t do. For example, I can’t download a .doc file. Also, it is quite troublesome to constantly transfer files over with a memory stick, so I decided to set up SSH.
Little did I know how pathetically paranoid the IT technicians were.
Problem 1: setting up SSH and connecting to my dynamic IP.
The first step was to install (
emerge openssh) and set up SSH. (I run Gentoo- the steps will be different for your distribution or if you are running Windows – say, you can set up SSH on Windows, can’t you?) This was simple. Now the problem here is that my IP keeps on changing. Especially because my ISP’s connection is quite volatile, my IP is dynamic and resets several times a day. The method to solve this was to set up a dynamic dns, available from dyndns.org. This is a free service, and allows me to connect to a sane domain name whilst a client running on my machine updates it regularly on the latest IP.
Problem 2: port 22 is blocked.
The next day I popped PuTTY on a thumb drive and tested it out – or at least tried to. I had a network connection refused error. Later that night I learned that most public networks blocked certain ports, for example port 22 which SSH normally uses.
The fix around this was to change the config in
/etc/ssh/sshd_config to use Port 443. You see, whilst http:// defaults to port 80, https:// URLs default to port 443 – and are hence rarely blocked. Et Voila – you can now connect! However, I also run an Apache webserver. This clashes as it also tries to use port 443. As I don’t care to serve SSL webpages on my localhost, I decided it was a decent sacrifice, and I removed Apache’s HTTPS support by removing `
-D SSL -D SSL_DEFAULT_VHOST` from
/etc/conf.d/apache2. Tada. I can now access SSH at my college.
Problem 3: What about SCP? Surely you’d want to copy files over.
Well, transferring files over is another issue. It’s all good with your vast array of Command-Line-Interface applications for IRC, Vim text editing, file browsing, MSN, email, calendar and PIM, etc – but every so often you will have the need to transfer a file over. Sending yourself an email with a file doesn’t help, as my college blocks almost every single website out there aside from Google.com (note: Gmail is not Google.com – so it is blocked too). At the same time, it also blocks downloading every single file type aside from image files. The quick fix for this was to put the file on my Apache localhost, change the file extension to a .jpg or something then download it from there.
But no. Two problems occured. 1) My website was blocked – haha, and 2) the IT technicians filter it not by extension, but by actual file contents. To get past the website block, I run a proxy script on my webserver (there are plenty of free proxies out there too) to access my webserver. But then of course I’m stuck with the file filter. So looks as though it’s game over.
Not really, there’s always SCP. I couldn’t send files using my computer as I didn’t know the network information of my college network. So I decided to SCP using the college’s Windows computer. I hear there’s a program known as WinSCP which is pretty nifty, but at the time I only had PuTTY’s collection of tools and thus PSCP.EXE – which pretty much did the same thing – with one catch: it’s a CLI application. You see, they’ve also blocked the command prompt. OK – for understandable reasons.
To get myself a command prompt, I did the age old innocent command.com trick. This involves creating a plain text file (eg: .txt), putting the words `
command.com` in it, and then saving it as cmd.bat. (Notice the changed file extension). This will give you a prompt to work with. Now – using that to run PSCP.EXE, I succesfully transferred my target file over – which was in this case a .doc file, which contained some homework.
What about the ethics of this?
Well. I personally feel as though these workarounds are anything but a way for me to do my work conveniently. The computer system is riddled enough with viruses as it is without my doing, and I doubt anybody will be motivated enough to have such a complicated setup unless they were either particularly vicious or needed a file really urgently (such as me at the time). But seriously – a learning centre blocking .doc files?
If you have more experience in networks than me and feel as though this article is innappropriate, feel free to contact me and I’ll willingly take it down.