In this post, I'll show you how to access the EC2 instances that you've deployed on the AWS network. There are two primary methods for accomplishing this. SSH into an EC2 instance is the first way to connect to it. This entails leveraging key pairs to establish a secure connection between a local client and an AWS server. The second method is to use the AWS Systems Manager Session Manager. I'll illustrate both ways and compare their security. First and foremost, Let's investigate SSH.
SSH into an EC2 Instance
SSH, or Secure Shell, is a network protocol that will allow you to connect our PC to an EC2 instance in a secure manner. From command line, you will be able to operate the AWS EC2 instance. Before you begin, there are a few prerequisites that must be met.
- You must have an instance operating in a public subnet.
- Instance security group that enables SSH access – This will utilise the TCP protocol on port 22.
- Having access to a key-pair – Generate a key-pair for the instance and save it to your computer.
For this post, I used a Mac. If you want to navigate through this with Windows, checkout AWS documentation.
Note: See this article for details on how to SSH onto an instance in a private subnet using agent forwarding.
Assuming you've completed the prerequisites, ensure the EC2 instance's state is "Running."
Make sure SSH is available on your local system. To verify that SSH is working, use the command "ssh" into your terminal. If not, You can download OpenSSH on Windows, Linux, or Mac in order to gain SSH access.
Navigate to the EC2 console once the key-pair has been generated and the instance has started. Now all you have to do is locate the public IP address. With this information, you may connect to the instance using a few commands at the terminal.
Use the following command to gain SSH access to the EC2 instance:
ssh -i /path/my-key-pair.pem my-instance-user-name@my-instance-public-dns-name
You are likely to get a simple error after running this command, If you get something like "Unprotected Private Key File", it's because of the permissions to your .pem file, the .pem file has permissions 0644, according to the error. To modify these permissions, use the below mentioned command. If a .pem file is public, EC2 instances will not accept it. The permissions of your .pem file will be changed using this command.
chmod 0400 my-key-pair.pem
Now you can run you SSH command again and most likely you will be able to SSH into your Instance.
AWS Systems Manager's Session Manager
The AWS Systems Manager Session Manager is another way to acquire access to an EC2 instance. You can manage EC2 instances, on-premises instances, and virtual machines using the session manager. How is it different from SSH into an instance, you might wonder? I'll get to it as soon as I can, but first let me show you around the Session Manager.
Before you begin, there are a few prerequisites for utilising SSM that must be met.
- You must have an Instance.
- You will need to install the SSM Agent depending on the instance. Session Manager will be able to control your running EC2 instances thanks to the SSM agent. It is already installed on the EC2 Linux 2 AMI. The SSM agent must be installed on all On-Premises servers.
- Create a new IAM role for Ec2. The AmazonSSMManagedInstanceCore can be found under Permissions policies in IAM Console. This grants access to your EC2 instance to the Systems Session Manager.
After you've set everything up, you may connect to the instances using the session manager. All of this can be done using the AWS Console! Since we've completed the prior prerequisites, the instances will appear in Systems Manager's Managed Instances page.
Now navigate to the Session Manager under Systems Manager.
If everything is configured everything according to the requirements, you will find your instance like below.
Select the instance you want to access and start the session.
You will be using a Secure Shell fully within the AWS dashboard to access the instance. In this section, you can execute any Linux command required to finish your assignment.
That's all there is to it. If your instances are running and allow SSM access, gaining access is as simple as clicking a few buttons in the AWS interface. When you have the AWS CLI enabled, you may also use a simple one-line command.
The primary difference between these two approaches, as you can see from these examples, is how you gain access to the instance. A security group rule is used to open a port using SSH. On the other hand, Systems Manager Session Manager uses an IAM role. Each of these solutions is straightforward to implement, but which is the superior option?
The session manager will be preferable in the vast majority of use cases. Session manager has a number of advantages, the most important of which is security.
Let's check it by comparing both with the principles of the AWS Well-Architected Framework on Security.
Enable Traceability Implement a strong identity foundation
- Enable Traceability
- Implement a strong identity foundation
You don't have to expose a port to SSH traffic while using session manager, therefore you prevent any risk of users exchanging keys. Because the Session Manager runs within the AWS interface or AWS CLI, each session is associated with a single IAM user. This enables a high level of traceability.
Systems Manager can leverage a range of AWS services for logging and auditing. You may enable CloudWatch, CloudTrail, or S3 through the Systems Manager console. When considering the AWS Well-Architected Framework, this is a must.
Overall, both techniques provide rapid and simple access to EC2. Because they are both equally simple to set up, I would go with the one with higher security which is Session Manager. You can also see everything within the console as an added benefit.