Still Using EC2 Key Pairs? Switch to Session Manager Now!
Still Using EC2 Key Pairs? Switch to Session Manager Now!
If you have ever launched an EC2 instance, you must be familiar with how AWS asks you to select or create a key pair just before you launch the instance. Here is a quick reminder:
This applies to both Linux & Windows instances and has been the way to access EC2s since the beginning. Although this way of accessing VMs is much more secure than simple password-based access, it still has some drawbacks:
Assuming you want to SSH into an instance from a computer on the public internet, either your EC2 needs a public IP or you need to take on the overhead of creating, paying for, and managing one or more bastion hosts.
The SSH or RDP port on your instance must be open and if you restrict IPs that are allowed to SSH or RDP in, you have to manage that too.
You must take care of the storage and distribution (to authorized personnel) of the SSH private key. Given the sensitive nature of this one file, you can’t just save it to your hard drive and give it out to anyone who asks. You have to design a secure storage and access strategy for these keys or they will quickly become unmanageable as the number of keys in your account grows.
Session Manager is a part of the AWS Systems Manager service. It is now the recommended way to connect to EC2 instances. It solves all of the issues we mentioned above and provides much more functionality around this.
Surprisingly, many people use SSH keys for their instances even today! Apparently, knowledge of the Session Manager is not very prevalent. And the fact that the EC2 console still prompts the user for a key pair before launching an instance, doesn’t help the cause either. Hence the need for this article!
The end goal is straightforward: it should be possible to log into every EC2 instance in an account from the Session Manager in the same region and account. Session Manager makes this possible without any keys or open ports involved!
So how does it work? Well, there are two parts to this that work together:
First, there is an agent running on your instance that talks to the Session Manager.
Second, your EC2 instance should have assumed an IAM role that lets the agent inside talk to the Session Manager.
Session Manager IAM Role
Let us first look at how to create an IAM role that you can use with any EC2 instance that should be connectable from Session Manager.
Start at the IAM console & click Create Role:
Select EC2 & then the managed policy AmazonSSMManagedInstanceCore on the next page. This is the policy for the EC2 role to enable Systems Manager core functionality. This policy grants the following permissions:
When you launch an EC2 instance, for it to be able to use Session Manager, you must install the SSM agent on it. SSM agent is preinstalled on Amazon Linux & Ubuntu. For instructions on installing the agent on other operating systems, refer to this documentation page.
Now that you have the prerequisites ready, let us launch an EC2 instance and access it via Session Manager. Follow the standard flow for EC2 launches except for the following:
Select the IAM role you created earlier as the instance profile.
If your AMI doesn’t have the SSM agent preinstalled, add user data scripts to install it.
Finally, at the prompt for the key pair, select “Proceed without a key pair”:
If your EC2 instance is in a private subnet (without internet access to public IP), there is one additional step to using Session Manager. This is because the SSM agent running inside the instance needs to be able to communicate to the Session Manager public endpoint.
If you cannot grant access to this endpoint, create a VPC endpoint in the subnet where your instance resides. This should be an interface endpoint (with DNS enabled) to the AWS service “com.amazonaws.ap-south-1.ssmmessages”. Here is a snippet of the “Create Endpoint” screen for reference:
There you go! You’re in! That’s all it takes to SSH into an EC2. Wasn’t that easy?
Session Manager has numerous advantages (and features) over traditional key pair-based access:
No bastion hosts required.
No SSH keys to manage.
No SSH/RDP ports need to be opened.
Session Managed works for both Linux and Windows.
It maintains session history.
It provides centralized access control over who can access your instances.
It has full auditing capabilities to ensure compliance with corporate policies.
Configure idle session timeout from 1 to 60 minutes.
Sessions use TLS 1.2 by default. You can further encrypt session traffic with a KMS CMK you provide.
Sessions connect as “ssm-user” by default. You can configure which Linux user an IAM user should log in as. To do this, tag an IAM user or role with the tag key SSMSessionRunAs and specify an OS user name as its key value.
Session logs can be captured in CloudWatch and/or S3 for troubleshooting/debugging purposes.
Get SNS notifications when sessions are started to critical instances.
Predefine session profiles for Linux/Windows with environment variables, shell preferences, or commands you want to run when your session starts.
Use AWS CLI’s SSM command to connect to sessions.
Forward any port in your remote instance to any port in your local computer. Then connect to this local port to access any applications running on the corresponding remote port.
I hope you are now convinced about how much better Session Manager is compared to traditional SSH. You can make it the default for all instances in your environment and take advantage of the numerous benefits. 😊
About the Author ✍🏻
Harish KM is a Principal DevOps Engineer at QloudX & a top-ranked AWS Ambassador since 2020. 👨🏻💻
With over a decade of industry experience as everything from a full-stack engineer to a cloud architect, Harish has built many world-class solutions for clients around the world! 👷🏻♂️
With over 20 certifications in cloud (AWS, Azure, GCP), containers (Kubernetes, Docker) & DevOps (Terraform, Ansible, Jenkins), Harish is an expert in a multitude of technologies. 📚
These days, his focus is on the fascinating world of DevOps & how it can transform the way we do things! 🚀
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.