Avoid Sharing Key Pairs for EC2

Lock and key devices are used by mankind for more than 6.000 years. Whether mechanical, electrical or digital, the concept stays the same: a key is needed to access resources behind a lock. Technology has made incredible progress since then. But one problem is still the same: managing keys.

After installing a lock, you need to answer the question: Who needs a key?

• With each key you hand over the risk of misuse increases.
• With each key you withhold the effort of accessing resources increases.

Balancing these oppositions is an important part of managing keys. And it’s getting more and more complex with each additional lock.

EC2 Key Pairs

A key is needed to access an EC2 instance over SSH. The key consists of a private key and a public key called Key Pair.

You are able to manage your keys with the help of the AWS Management Console. The following example shows a screenshot of a Key Pair named mykey.

The key management allows you to create, import and delete multiple keys for the use with EC2 instances.

When you launch an EC2 instance you can select one of your keys to allow SSH access. AWS will then add that key to your instance. The last step when starting an EC2 instance via the AWS Management Console is shown in the following screenshot.

In this case the Key Pair named mykey was chosen. The key mykey is needed when establishing an SSH connection to that EC2 instance.

ssh -i ~/.ssh/mykey ec2-user@52.123.456.789

AWS implemented a secure way to manage keys to authenticate when establishing a SSH connection.

Problematic Default

If you read through security guidelines, for example the Operational Checklists for AWS (not available anymore) you will always find the same requirements for SSH keys:

• Every user uses its own SSH key. Don’t share keys between users.
• Access to EC2 instances via SSH is restricted to the minimum number of users. Only users who really need to be able to log into an EC2 instance are able to do so.

Unfortunately it is only possible to select a single Key Pair when launching an EC2 instance. And it’s not possible to change the Key Pair for a running EC2 instance.

That’s one reason why I’ve seen many AWS accounts with shared Key Pairs while doing Security Reviews for my consulting customers.

Solution

Adding multiple keys to an EC2 instance is possible with the help of User Data. User Data allows you to provision an EC2 instance during bootstrapping.

The following example includes a cloud-init configuration. The configuration contains two users jdeoand jroe and their public SSH key, the public part of the Key Pair.

#cloud-config
users:
  - default
  - name: jdoe
    gecos: John Doe
    ssh-authorized-keys:
      - ssh-rsa ...
  - name: jroe
    gecos: Jane Roe
    ssh-authorized-keys:
      - ssh-rsa ...

This allows you to add the public parts of your Key Pairs to your CloudFormation template. You are able to manage your keys with the help of Infrastructure as Code. The cloud-init script from above is embedded into the CloudFormation template.

The following example shows a CloudFormation template including an EC2 instance.

"EC2Instance": {
  "Type": "AWS::EC2::Instance",
  "Properties": {
    "ImageId": "ami-bff32ccc",
    "InstanceType": "t2.micro",
    "SecurityGroupIds": "...",
    "SubnetId": "...",
    "UserData": {"Fn::Base64": {"Fn::Join": ["\n", [
      "#cloud-config",
      "users:",
      "  - default",
      "  - name: jdoe",
      "    gecos: John Doe",
      "    ssh-authorized-keys:",
      "      - ssh-rsa ...",
      "  - name: jroe",
      "    gecos: Jane Roe",
      "    ssh-authorized-keys:",
      "      - ssh-rsa ..."
    ]]}}
  }
}

There isn’t just one way of doing it. So let’s have a look at other solutions as well.

More Solutions

Think about the Key Pairs as a delivery artifact that needs to be deployed onto your EC2 instances. Other solutions to manage Key Pairs for EC2 instances are:

• Use CodeDeploy and a delivery pipeline to add, update, or delete keys on your EC2 instances.
• Use the AuthorizedKeysCommand of SSH to load keys on-demand.
• Integrate SSH authentication with a directory service or identity broker (e.g. Active Directory, LDAP, …)
• Get rid of SSH access. I’m not joking. Infrastructure as Code, Automated Deployments, Centralized Logging and Monitoring allows you to turn off SSH completely.

Summary

Two simple rules for using Key Pairs to control access to EC2 instances via SSH:

1. Every user uses its own SSH key. Don’t share keys between users.
2. Access to EC2 instances via SSH is restricted to the minimum number of users.

EC2 doesn’t support multiple Key Pairs by default. And updating Key Pairs (adding new keys, replacing existing keys, or deleting existing keys) is not supported by default.

User Data allows you to deploy a bunch of Key Pairs on an EC2 instance during bootstrapping. CloudFormation and cloud-init simplify the task of creating users and adding the public part of their Key Pairs to an EC2 instance.