Posts Tagged ‘aws’

SSH to EC2 Instance and GitHub on a Mac

Yup, I’m moving to the Mac.  It’s really cool – it has this terminal thingy that you can just type commands into – what an elegant interface!  Simple black and white and it’s real clear that all I need to do is type!  😉

A windows user asked me how to log into an Amazon EC2 instance using SSH.  I said, “um, well , you, wait, I was just doing this … um.  I’ll look it up and send you instructions.”  Yes, I had already done it, but was confused because I was actually in the middle of setting up secure access for GitHub as well.   I’m going to host some demos for the EventBus (particularly for Apache Pivot) on GitHub since my project on java.net will forever be stuck in CVS even though new projects can use SVN or Mercurial.

So let’s configure this Mac to talk to a new EC2 instance, then allow it to hook up to GitHub too (in a second post).  That might be mildly interesting since there may be a cat of keys involved – OK, maybe not interesting anyway.

To use ssh on an EC2 instance, ensure that when you create the instance, you also create a security group with port 22 open, since that’s what SSH runs over.   You will also create a keypair.  (You don’t need the Access Key Identifiers that you use for command line tools.  The ssh keys for an instance are different from the Access Key Identifiers and are created when you create (or reuse) a keypair for the instance. )

When you create the keypair for the instance you are prompted to download the key file (pem).  This is the private part of the keypair.  If you lose it, you are out of luck, AFAIK.  By default, on my Mac using Firefox, the download, the private part of the pair, gets downloaded to /Users/mbushe/Downloads/<name-of-key-pair>.pem.  The public part of the keypair is held on the server.  You will be forced by ssh to protect your private key, so run:

chmod 700 /Users/mbushe/Downloads/<name-of-key-pair>.pem

..so that only you can access it on your local box.  I’m going to assume you are connecting as root, but a good image will have you connect as another user, set up special.  (OTOH, sometimes you have to log in as root.  For example, if you are using a Content Management System that opens the CIFS port, you need to log in as root since it’s under 1000.)  The supported Alfresco EC2 image will boot you if you log in as root and ask you to in as ubuntu.

To connect using ssh as root, do the following (I’m giving all my info since I’m trashing this instance and key anyway):

ssh -i /Users/mbushe/Downloads/my-key-pair-name.pem root@ec2-67-202-0-107.compute-1.amazonaws.com

You will get this:The authenticity of host ‘ec2-67-202-0-107.compute-1.amazonaws.com (67.202.0.107)’ can’t be established.
RSA key fingerprint is 24:e6:b6:62:fd:f3:54:c0:5f:86:06:97:8d:b7:d4:4f.
Are you sure you want to continue connecting (yes/no)?

At this point, you are connecting with something out there in the world that has a public key with a certain fingerprint that’s displayed.  Some nafarious teenager in your neighbor could be sitting on your wireless network and be running a DNS server for you that points you to his machine instead of yours, or someone scarier anywhere between you and what you are connecting to.  My neighbors likely haven’t hacked into my amazon box and stolen the public key though.  Can you trust everyone on Amazon’s staff though?  If I wanted to cause trouble, that’s the job I’d be applying for. This is why Bruce Schneier consults on human hacks now.  But to limit the risk, you should connect to your AWS console, click on the instance (not the keypairs), and show the system log.  Likely somewhere near the bottom, you’ll see the keys for the fingerprints:

ec2: #############################################################
ec2: -----BEGIN SSH HOST KEY FINGERPRINTS-----
ec2: 2048 66:27:32:9f:05:f7:84:97:53:f4:53:46:67:36:5f:6d /etc/ssh/ssh_host_rsa_key.pub (RSA)
ec2: 1024 00:84:16:fd:4e:5f:7d:8d:07:20:40:1a:e3:36:0b:94 /etc/ssh/ssh_host_dsa_key.pub (DSA)
ec2: -----END SSH HOST KEY FINGERPRINTS-----
ec2: #############################################################

Look at the RSA fingerprint from the system log and see if it matches the output of ssh.  If it does, type yes, get warm fuzzy feelings and continue on.  If it doesn’t type no and trash your instance!  Hopefully you set up your instance via a script you can run again on a new instance.  Isn’t virtualization great?

Advertisements