The Agile Micro ISV Blog

3 Things You Didn't Know About SSH - Part 2

Image via Wikipedia

OK, so last time we looked at how to tunnel your web traffic over SSH to increase security, privacy, network restrictions etc. Today, we'll look at how to use port forwarding to access servers that are ordinarily available on the internal network.

Subversion Over SSH
As an example, I'll show you how I access my internal network's Subversion server. Here's my set up:

• Externally, I have MyDomain.com which resolves to my home IP.
• On the internal network, my Ubuntu server has the address 192.168.1.101.
• The server runs an OpenSSH server and the Subversion svnserve daemon.
• The router forwards incoming connections on port 22 on to my server.

Setting up the tunnel, we do the following:

putty -L 3690:localhost:3690 username@MyDomain.com

Log in as usual. This time, the SSH tunnel has been set up such that any connections to 127.0.0.1 on port 3690 will be tunnelled to port 3690 on the server. Which, handily, is the default port used by the svnserve daemon.

And to get hold of some part of the remote repository, we just do:

svn co svn://127.0.0.1:3690/MyRepo

And hey presto, tunnelled access to your internal SVN server. It's always puzzled me why the good SVN folks suggest their weird svn+ssh hack, which launches an svnserve instance in user space, potentially causing file locking problems and requires user access to the svn database files.

This technique can be applied to any internal server, whether web, database, remote desktop etc.

Next time we'll look at reverse tunnels. Very cool.

Related articles by Zemanta

• 3 Things You Didn't Know About SSH - Part 1
• SSH Tunnel 4.0
• SSHing for fun and profit
• Keeping your SSH connections alive with autossh
• Automate a Remote Login Using SSH-Agent
• Meerkat: simplified SSH tunneling

Rant: Is This The Worst Week In Google's History?

Image via CrunchBase, source unknown

This last week, we've had GMail, Google Apps, Feedburner and Google customer service all overflowing with FAIL.

If you want to be considered a leader, start acting like it. Pick up the bloody ball Google!

Edit: Not that I'm suspicious or anything, but about an hour after I posted this, this site dropped out of Google's rankings for about an hour.

Related articles by Zemanta

• Swapping Google for Microsoft
• Google Apps Email Down
• Google on Gmail: Sorry
• Gmail Goes Down - Twitter Survives
• Gmail's Out...Again
• Where are you left if the Cloud goes down?
• Gmail users hit by outage again
• Gmail frustrates users
• Gmail Outage Prompts Google Mea Culpa, Panic Subsides

3 Things You Didn't Know About SSH - Part 1

In mine, the humblest of opinions. SSH is one of the most underused tools in the web worker's arsenal. I'm going to show you 3 little known techniques for using secure tunnels to not only increase security and privacy, but also to circumvent roadblocks to network access.

We're going to need 2 things. A server running OpenSSH, and an SSH client. I have an Ubuntu server under my stairs, and I have full shell access at my shared server at DreamHost, so I have 2 options, depending on what I'm doing. We also need a client. If you're running Windows, you will need to grab Putty. If you're on Linux, you're already set. I don't use Macs, but I'd be surprised if they didn't also ship with an SSH client.

Tunnelling Your Web Traffic
Maybe you're in Starbucks using an unsecured wifi hotspot. Maybe you're behind a fascist corporate proxy. Maybe the NSA is watching you. Whatever the reason, tunnelling your web traffic with SSH is trivial.

You see, every SSH client has the capacity to turn itself into a SOCKS5 proxy. Nifty eh? What does that mean? Well, if we launch the client like this:

putty -D 8000 username@myserver.com

You'll be prompted for your password, just log in as normal. It just looks like you're into your shell. Something else has happened though - your client has set up a SOCKS5 proxy accepting connections on 127.0.0.1 port 8000. Any applications set up to use this proxy will send their traffic through the SSH tunnel, and out the other side at the server end. Let's try it.

Go to www.whatismyip.com. This is your IP address. Now go to wherever in your browser you set up a proxy, and enter 127.0.0.1:8000 under the SOCKS proxy entry. Here's an example of doing it in Firefox:

Now reload the page at www.whatismyip.com. The IP address it reports should have changed to the IP address of the SSH server. Your traffic is now tunnelled.

Is that it? Probably. The only limitation of this is that DNS traffic is not tunnelled. This is what is usually termed DNS leakage.

But Firefox, bless its cotton socks, has a trick up its sleeve. If you type this in your Firefox address bar, and click past the amusing warnings:

about:config

You're into the Firefox configuration area. You could really bust stuff in here so pay attention :)

Scroll down until you see this:

network.proxy.socks_remote_dns

Change the value to true. And that's it. Firefox is now kindly tunnelling your DNS traffic through your tunnel, and you're super secure. Even a rogue hotspot with poisoned DNS can't hurt you know. Cue evil laughter.

Next time I'll show you how to turn SSH into a poor man's VPN, but without the hassle of setting up a VPN server.

Related articles by Zemanta

• Meerkat: simplified SSH tunneling
• BitTorrent: Bypass any Firewall or Throttling ISP with SSH
• Download Torrents Anonymously with TorrentPrivacy
• Make Your PC Phone Home: How to Access Your Computer Remotely
• SSHing for fun and profit
• ssh-xfer: Quickly grabbing files over an existing SSH connection
• SSH Tunnel 4.0
• Keeping your SSH connections alive with autossh