Please use the menu below to navigate the article sections:
In this article, I will walk you through a variety of ways to access the EC2 instances that you deploy on the AWS network. There are two main ways to achieve this. The first way to connect to an EC2 instance is to SSH into it. This means creating a secure connection from a local client to the AWS server using key pairs. The second way will be to utilize the AWS Systems Manager Session Manager. I’ll demonstrate both these methods and compare the security of each. First off, I will look into SSH.
SSH into an EC2 Instance
SSH or Secure Shell is a network protocol that will allow you to securely connect our machine to an EC2 instance. You will be able to control the AWS EC2 instance from our command line. Before you can do this, take care of a few requirements.
- AWS ACCOUNT SETUP – We need to have our AWS account set up and ready to launch instances. Check out the AWS documentation for specifics on how to configure your account correctly.
- RUNNING EC2 INSTANCE – You need to have a running instance in a public subnet. The instance launched in this article will be the Linux 2 AMI. It is in the free tier on AWS. Check out the AWS Documentation on how to launch an instance. The instance needs a few specific configurations:
- Security Group that allows for SSH access – This will use the TCP protocol on port 22.
- Access to a keypair – Create a keypair for your instance and download it to your local machine.
- Linux or Mac – For this portion of the tutorial, I used a Mac. If you want to navigate through this with Windows, here is a link to the AWS documentation.
Note: For instructions on how to SSH into an instance in a private subnet with agent forwarding, see this article: https://digitalcloud.training/ssh-into-ec2-in-private-subnet/.
Given that you have the prerequisites taken care of, make sure the status of the EC2 instance is “Running”. You can see this demonstrated below.
Check that SSH is available on your local machine. In order to check that you have SSH running, just run the command “ssh”. As you can see below, my Mac recognized the command. This signals that the SSH client is working on my machine.
Many computers will have the SSH client already installed, but some won’t. You can download OpenSSH on Windows, Linux, or Mac in order to gain SSH access.
With the keypair created and instance running, navigate to the EC2 console. Now, you just need to find the public IP address. With this information, you can run a few commands in the terminal to connect to the instance.
The public IP address will show up at the bottom of your console when you select the running EC2 instance.
In order to again SSH access to the EC2 instance, use this command below:
ssh -i /path/my-key-pair.pem my-instance-user-name@my-instance-public-dns-name
Before running the command, navigate to the directory where your key pair is stored. Run the SSH command.
After running this command, I ran into a very common error.
The AWS documentation provides the command to remedy the situation. The error code states that our .pem file has permissions 0644. Run the chmod 0400 to change these permissions. EC2 instances will not accept any .pem file if it is public. This command will change the permissions of your .pem file.
With that error fixed, run the SSH command from earlier.
And there you have it! You have successfully navigated into the EC2 instance. From here, you can run commands in the Linux terminal of our instance!
Once you figure out the permissions of the .pem file, this is a very straightforward process. This is not the only way to gain access to an EC2 instance. There are multiple other options, but I will look at the AWS Systems Manager next.
AWS Systems Manager Session Manager
Another option to gain access to an EC2 instance is the AWS Systems Manager Session Manager. The session manager allows you to manage EC2 instances, on-premises instances, and virtual machines. You might be asking yourself, why is this so different than SSH’ing into an instance? I will answer that soon enough, but first let me walk you through the Session Manager.
Just like the last scenario, we need to take care of a few requirements in how we set up our instances.
- Have an AWS Account
- Launch a running instance in an AZ. Session Manager will not start instances on its own, rather it will manage them.
- Install the SSM Agent IF not already installed. Depending on the instance, you might have to install the SSM Agent. The SSM agent is what will allow Session Manager to control your running EC2 instances. The EC2 Linux 2 AMI does already have it installed. For any On-Premises servers, installing the SSM agent is mandatory.
- Set an IAM Role. If you search for AWS provided IAM roles, you will find the EC2AccessForSSM. This allows for the Systems Session Manager to access your EC2 instance.
Once again, here is the running instance:
With all this configured, you can use the session manager to connect to the instances. This can all happen through the AWS Console! Given that we have met the previous requirements, the instances will show up under the Managed Instances tab in Systems Manager.
Notice that we did NOT set up a security group. There is no SSH access allowed on the EC2 Instance. This is the major difference between the Session Manager and SSH.
In Systems Manager, navigate to the session manager. Select Start Session.
You will be presented with any instances that are being managed by Systems Manager. Select the instance you want to access and start the session.
You will be using a Secure Shell inside the instance entirely in the AWS console. In here, you can run any Linux command necessary to complete your task.
And it’s as easy as that. If your instances are running and allow SSM access, all it takes is clicking a few buttons in the AWS console to gain access. You also have the ability to utilize a simple one line command when the AWS CLI is configured.
As you can see from these demonstrations, the main difference between these two methods is how to gain access to the instance. With SSH, you open a port through a security group rule. Systems Manager Session Manager utilizes an IAM role to connect with the instance. Each of these methods is simple to implement, but which one is better?
For the majority of use cases, the session manager is going to be superior. The main advantage for session manager is security.
Two of the principles of the AWS Well-Architected Framework on Security apply to this demonstration:
- Enable Traceability
- Implement a strong identity foundation
With session manager, you don’t have to expose a port to SSH traffic, therefore you avoid any risk with users sharing keys. Because the Session Manager occurs inside the AWS console or AWS CLI, each session is tied to only one IAM user. This allows for a great deal of traceability.
There are a variety of AWS services that Systems Manager can use for logging and auditing. Inside the Systems Manager console, you can enable CloudWatch, CloudTrail, or S3. This is a necessity when you consider the AWS Well-Architected Framework.
Overall, both methods are quick and easy ways to gain access to EC2. Because they are similarly easy to implement, I would choose the one with better security in Session Manager. As a bonus, you can view everything inside the console.
AWS Training Courses
Amazon EC2 features in several of our AWS certification training courses including the following:
- AWS Certified Cloud Practitioner
- AWS Certified Solutions Architect Associate
- AWS Certified Developer Associate
- AWS Certified SysOps Administrator Associate
- AWS Certified Solutions Architect Professional