There are many approaches to connecting to servers long-term. For Linux, the default is to use SSH without a password. All the examples will be based on Linux servers, so SSH is what we will use.
While access to a server with only one form of authentication (SSH in this case) can be a security nightmare, security is never about just one type of control, but rather a series of controls that (ideally) overlap.
In these examples, we will be relying on SSH without using a password, and will couple this with the use of AWS Security Groups to ensure that access to any instance over SSH is restricted to only specific IP addresses. That's not all of course (any machine I allow to connect is a potential attack vector including my workstation), and IP restrictions are one of the best secondary protections available. Appropriately when creating a new instance I ensure it has a restrictive Security Group enabled. This of course is a post for the future, so lets get back to SSH keys.
SSH keys are based on a public and private key pair (for every private key that you need to protect there is a public key you can give away safely), which is quite different to the traditional username/password system you may be used to. Having a public/private key pair is considered asymmetric-key encryption in that one side of the key can be stored in many locations and shared (hence 'public'), with the private side of the key pair protected. A password as such is the basic example of symmetric-key encryption where the password (or key) is the same on both sides of the encryption and decryption.
Knowledge of a password allows authentication no matter where it is used - for SSH, only knowledge of the private key is considered important as while anybody can have access to the public key, you can't use that public key to authenticate against another system that only has the public key. Thus you can put the public key anywhere without creating a massive security vulnerability.
Hopefully the above gives you the background to make the statement 'keep the private key secure' more than just a phrase and something more understandable.
Before I forget to actually say it, 'keep the private key secure' :)
Within the AWS console, navigate to the EC2 panel and the SSH 'Key Pairs' section - the key is either created or imported into the EC2 panel, as this is how AWS enable a key for use against a standard AMI (Amazon Machine Image) when an EC2 instance is created.
If you don't already have a SSH key, one can be created within the AWS console. To create a key using the AWS console, use the 'Create Key' button:
Give your key a good name that will make sense long-term - I'd steer away from using a nonsensical name as knowing what a key is used for can be very important.
As part of creating the key, you will have the private key component saved either to your default save location or will be prompted to save the file. By default whatever you call the key in the above dialog will create a file with that name and the extension .pem. For example if you call a key ec2access then you will receive a key called ec2access.pem.
Alternatively, if you already have a SSH key you would like to use, then you can import the public side of the key pair you have already. Click the 'Import Key Pair' button, and use the 'choose file' button in that dialog to start the import process - just make sure you choose your public key:
Now that you have a key listed, you can create a new EC2 instance, and by using that key, are able to access it.
Next up, we will create the needed VPC and subnets required. More on that next post!