Yesterday we spun up our server in the cloud. Today we make it accessible online and log into it.

This server has an IP address already. There’s a problem with the one we have right now though: it’s not going to be stable over a long period of time. If we just point DNS to it now it’ll work fine — now. However, if the server needs to get recycled the new server will most likely get a different IP address throwing things off.

As an aside, this is a good time to point out that “cloud servers” are not magic. The micro instance we spun up is a virtual machine running on a bigger server somewhere in Oregon. That server is just like any other server you’ve ever seen: it can fail. Amazon specs our servers pretty well and I’ve not personally had to deal with a server getting pulled out from under me, but it can happen.

Elastic IPs

EC2 has a solution to the IP address problem: Elastic IPs. If you create an elastic IP, that address will outlive the server. Not only that but it can be assigned on-the-fly to a new server. This isn’t as important to us right now, but it’s a cool feature none-the-less. (I might explore this later if I talk about scaling this server up…)

Creating one is easy!

At this point we have an IP address pointed to nothing. All we do right-click on the address and “Associate Address” to point to our already running instance.

Once you click “Associate” the instance you have running will get that new address. Easy peasy.

Setting up DNS

This is a topic I’m going to punt on for now. Typically whatever domain registrar you got your domain from (you got a domain, right?!) has some feature to point a name to an address. What you need to do is point “www” or “blog” or whatever you want to the elastic IP you just got handed.

If your registrar doesn’t serve DNS, you can still get things up and running using Route 53, which is an additional AWS service. It’s an easy thing to do. If there is demand, I’ll gladly post a walkthrough for both Route 53 and GoDaddy (my registrar) to show you the ins and outs.

SSH – the Secure Shell

Mac or Unix

If you have a Mac or are running some flavor or Unix (like Linux for instance) you’re lucky. This is easy.

Remember that key you downloaded yesterday? Just open up a terminal window and go to that directory.

Let’s pretend you’ve put it on your desktop on the Mac:

cd ~/Desktop
chmod 0600 your_key.pem
ssh -i your_key.pem [email protected]your-ip-or-name

The first line just changes directory to wherever you saved your key. (Your desktop might not be the best place for it by the way) The second line, which you only have to run once, set the permissions of the file so only you can read it. If you didn’t do that, ssh would bitch about it. The last line starts up the connection. It didn’t ask for a password since they key is the password. Remember to keep it safe!

Windows and SSH

This is a bit trickier. Not harder, just more steps. There are some other ways of doing this, like using Cygwin, that make your Windows machine feel a lot more Unix-y. I’m going to stick with what most people do.

First you have to download PuTTY from http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.

Download both PuTTY and PuTTYgen since you’ll need both.

PuTTY is quirky since it can’t use the .pem file you got from AWS directly, it needs to convert it to a .ppk file. Go figure — I’m sure there’s a reason, but I don’t really care enough to try to figure it out.

You’ll need to run PuTTYgen and “Load” your private key.

…then save it as a .ppk file. This bit of annoyance is now complete — you don’t have to use PuTTYgen any more.

Close PuTTYgen and run PuTTY itself.

On the Connection -> SSH -> Auth page browse to your just-save .ppk file.

On the Session page, fill in your server name or IP address. You might as well save it as a session so you don’t have to do this every time.

“Open” the connection!

The first time you’ll see the dire warning. Just roll with it. :-)

Log in as “ec2-user” as before, and ta-da!

Tomorrow, we’ll set up some software now that you know how to log on.