SSH Keys found in Account

SSH Keys that are available in an AWS account allow for provisioning of OpenSSH server and provide metadata information that can be utilised for research

Details ¶

SSH is a common tool for accessing remote servers, but it has been specifically targeted for attacks and has known vulnerabilities. While firewall rules and placing SSH targets behind a Load Balancer can mitigate these risks for targeted and time-sensitive connections, there are better solutions which we advise using.

We discuss the benefits of using AWS SSM in full under documentation for test A-EC2-4. There are few cases where utilisation of OpenSSH is preferred to usage of AWS SSM, therefore for the majority of accounts it’s best to migrate to AWS SSM usage.

After migration there is no need to retain SSH keys in AWS, therefore it’s best to remove any and all keys in the account.

As the keys stored in AWS are public keys they are not considered sensitive information. However, they can indirectly offer information such as the following:

• They indicate that SSH usage has occurred which undermines the SSM policy usage to personnel
• They can include meta data that can indicate information about the associated private key. For example, when creating an SSH key using tools such as openssh-keygen, the tool will default to adding a descriptive comment on the public key. This is commonly username@hostname which would indicate that the corresponding private key is owned by the user username on device hostname
• Public SSH keys can be baked into AMI Images copying the permission for the included key across all child builds
• The naming of SSH keys usually corresponds to staff names which makes the list of SSH equivalent to a list of all Administrators

Remediation ¶

Fixing this issue is as simple as deleting all AWS KeyPairs in the AWS Account. This will remove the keys from use as a provisioning resource for new and re-provisioned instances.

Deleting the keys will not remove them active instances, therefore users with access to the private key will still be able to access running instances.

Deleting the key will prevent new instances from using the key to provision OpenSSH and to distribute the key to the machine, providing access to anyone with access to the private key and network connectivity. Deleting the key will also prevent any instance scaling or orchestration tools from creating instances using this key. This may lead those orchestration tools such as AWS Auto Scaling Groups to fail, requiring intervention to reconfigure the group.

Pet vs Cattle ¶

The larger concern in deleting AWS KeyPairs are that it prevents usage of OpenSSH leading to a change in organisational policy and tools. This may be an approach towards removing all access to machines, therefore preventing any unregistered and unreplicable changes from being performed on the instance. Successfully achieving this level of inaccessibility to instances requires a thorough build, deployment and monitoring infrastructure alongside the governance, knowledge and resources. This is considered as adopting cattle machines, where each machine is a replaceable and homogenous resource that is a known entity that can be recreated as desired. This is the opposite of pet machines which are instances which are unique and irreplaceable, mainly as due to regular untracked changes they have become unknown entities that are difficult to recreate.

SSH Access tends towards management of pet instances rather than cattle instances. Therefore, an environment using OpenSSH keys is unlikely to have the governance and processes to immediately convert all their instances into untouchable and recreatable cattle.

Whilst deleting keys is easy, ensuring governance, tooling and the approriate training to users is a much more difficult challenge that takes experience to implement. If the adoption of secure cattle instances is important to your organisation, it’s best to get architectural support to provide the knowledge and guidance to adopt secure processes successfully: