Remote access to resources is one of the key elements of the day-to-day work of administrators or support engineers. Remote access is useful whenever local administration is not possible, or when resources are, for example, in the cloud.
This second case is a common element of consideration when working with my clients.
In this entry I would like to show you how remote access thanks to AWS Session Manager can be an alternative to the well-known SSH.
Remote access with 0.0.0.0/0
Today we will stay with classic virtual machines (a nod to serverless lovers). In the case of cloud resources, remote access can sometimes be problematic.
If we choose a landing in which we use standard access methods (SSH/RDP), we have to address the following challenges such as:
Firewall configuration: exactly, from which IP addresses will be possible remote access (because we do not want access from all over the Internet, right 😎),
How to connect to resources that are not directly accessible from the Internet (located on private networks),
There are companies where security policies prohibit the possibility of connecting after SSH/RDP to resources outside the physical location and then you have to look for a completely different solution.
Remote access to cloud resources
Now to all this, we will make the aspect that our resources are located somewhere far away and we do not have the ability to approach and physically “pet” our servers.
So if you are interested in alternatives, today will show you how using AWS Session Manager to easily and pleasantly make yourself “entry” to virtual servers.
AWS Systems Manager
AWS Systems Manager is a solution that addresses various aspects of operational management of cloud infrastructure as well as on-premises.
One of the tools included in this service is Session Manager, which allows you to get to a shell or remote desktop using a regular Internet browser.
So let's move on to the practical part and further focus on preparing and remote access to our sample server.
For the correct operation of the service, several elements are needed:
Supported operating system: at the moment virtually all versions of Linux, Mac OS, and Windows from 2012 to 2019.
SSM Agent: In order for the service to communicate properly with a managed machine, you need to install SSM Agent on it.
Call to Service — Agents must be able to connect to the appropriate end points of the service. Communication takes place after HTTPS (443) with:
Permissions: In addition, the issue of permissions remains: for EC2 machines, you need to prepare an appropriate IAM Role along with Session Manager permissions. Of course, I assume that our user also has the necessary permissions to use this service.
So, to work...
Step 1: Prepare IAM Role for EC2 services.
So that an agent on our machine can “legit” communicate with the Session Manager service, they go to the IAM service and there in the Roles tab I create a role for the EC2 service.
IAM Roles for EC2
It then adds permissions to communicate with Session Manager. For this purpose I will use the already ready-made IAM Policy Amazonec2ROLEFORSSM for my DEMO.
Further it remains only to give the appropriate name and create roles.
Step 2: Server Configuration and SSM Agent.
Now I will prepare myself a server to connect to. In this case, I will run a virtual server using the AWS AMI image that already has SSM Agent installed.
For other images, you can easily install such an agent. In this case, these two links can help:
Manually installing SSM Agent on EC2 instances for Linux
Manually installing SSM Agent on EC2 instances for Windows Server
Step 3: Pin IAM Role to the virtual machine.
Now for SSM Agent on your server to communicate with AWS System Manager, you need to pin the IAM Role created in Step 1 (which is exactly the IAM Profile that was created during the creation of the IAM Role).
If you start a new server from an image that already has an agent installed, it is enough to expand the Advanced details section during its creation and pin the previously created profile there.
In turn, if you want to attach a role to an existing server, it is enough to select the server in the console and select Actions - Security - Modify IAM Role from the menu after above.
And so choose IAM Roles from Step One.
Time to check the connection.
Time for a quick test, in the console you select your server, from the menu at the top you select the Connect button.
Then you switch to the Session Manager tab, if everything is configured correctly, the following window should appear.
However, if something is wrong, then here will also appear information that you need to verify the configurations.
So if it's ok, just click Connect and the console window should open in a moment.
And that's it...
What about servers on private networks?
That's one more thing at the end...
... what about when we have servers that don't have internet access or limited and controlled access is required?
As you remember above, it was about the need to communicate with the appropriate end points of the SSM service.
To ensure such communication we have two options:
Implementation of communication using NAT Gateway.
Using VPC Endpoint to provide a private connection to SSM.
This should work for you now... Cheers 😎