EC2 Instance Connect is an insecure default!
Two months before, Michael wrote about why AWS SSM is a trojan horse. Shortly after that, AWS released EC2 Instance Connect, which is even worse. If you use Amazon Linux 2 or Ubuntu, the chances are high that everyone in your AWS account can SSH into every EC2 instance!
Do you prefer listening to a podcast episode over reading a blog post? Here you go!
The SSH daemon (
sshd) needs to be configured to ask the metadata service for all public keys when someone connects via SSH. This configuration is enabled for you by default on Amazon Linux 2 and Ubuntu AMIs. We discovered this breaking change in November 2018.
Looking for a new challenge?
These three conditions must be met:
- Use the official Amazon Linux 2 or Ubuntu AMIs
- Allow traffic on port 22. If you used SSH in the past to manage your instances, the port is already open.
- Your IAM user or role needs permissions (action
ec2-instance-connect:SendSSHPublicKey). Very likely, you have those permissions thanks to managed policies like
You can now open an SSH connection to every EC2 instance in your AWS account.
If you are not interested in using EC2 Instance Connect, you can do one of the following:
- Uninstall EC2 Instance Connect.
- Do not allow traffic on port 22.
- Deny the action
ec2-instance-connect:SendSSHPublicKeyglobally in your SCP.
If you want to use EC2 Instance Connect:
- Keep your Security Groups as close as possible and use a VPN to connect to your VPC.
- Grant the
ec2-instance-connect:SendSSHPublicKeyaction carefully. According to IAM docs, you only can use a condition to restrict the OS user. According to the EC2 Instance Connect docs, you can also restrict access to specific EC2 instances using resource-level permissions. Unfortunately, EC2 Instance tags don’t seem to be supported.
AWS released a new feature called EC2 Instance Connect. It is enabled by default on Amazon Linux 2 and Ubuntu AMIs. We would appreciate if AWS would ask us - the customers - before they change defaults that increase our security risks. And we would also love to see up-to-date documentation on the IAM configuration. The information is contradictory at the moment, which is not satisfactory when security is at risk!