In this blog post, let us see, how to Connect to AWS EC2 Windows Instance in private subnet, with no ingress
Services used:
AWS IAM
AWS EC2
AWS SSM
AWS IAM
Identity Access Management service that helps us define the basic and most essential service of granting or denying permissions to a user or role. Thus created role, in this case, will be attached with policies as needed, and attached to the AWS EC2 Instance. This helps user accessing this EC2 instance to perform actions/tasks as required.
AWS EC2
Elastic Compute Cloud enables users to launch instances of our choice of operating system, CPU, memory, storage and many other parameters. Thus the capacity that we dont have physically can be obtained & used in minutes from AWS for pay-as-you-go basis
AWS SSM
AWS Systems Manager is most efficient service, that helps in organizing and controlling the inventory(EC2, On-prem servers) under single window, apply automations, change management to the EC2 machines by connecting to these instances
How to achieve:
We do port forwarding mechanism for target 3389(RDP) to the desired port number(ex. 3690) in source machine, from where we intend to connect. For this, we use AWS SSM port forwarding feature
Pre-requisites:
- An active AWS account
- Permissions to access AWS EC2, IAM, SSM services
- Attach IAM role with AmazonSSMManagedInstanceCore permissions and attach this to the EC2 instance that is created
- Latest version of SSM agent installed in Windows EC2 in order to use the port forwarding feature, AWS CLI in your base machine from where you connect to your Windows EC2
- Installation of freeRDP, Session Manager plugin in source machine(myTestInstance which is Amazon Linux EC2 instance here. Amazon Linux image because AWS CLI comes by default)
Steps:
- Login & navigate to the AWS EC2 management console
- Create or use a IAM role for EC2 with permissions to perform automation via AWS SSM
- Create o use a private subnet with no Internet Gateway
- Create or use a security group with no ingress ports
- From the EC2 console, launch a simple windows AWS EC2 instance
- configure or attach with no-ingress security group, and IAM role created earlier with AWS SSM permissions
- Launch the instance, watch it coming to "Running" state from EC2 console
- Ensure there is no ingress in security group attached to this new EC2 Windows instance
- Also find that the Windows EC2 instance has SSM Agent running by viewing it in AWS Systems Manager
Ensure about source machine(myTestIntance Linux EC2 in this example) Session Manager plugin installed & running
-
Connect to source EC2 instance via "EC2 Connect", apply the below command for enabling AWS SSM Port forwarding option against the desired local port. Basically, we are mapping the remote desktop port of windows EC2 port 3389 to 3690 of the localhost
aws ssm start-session --target <> --document-name AWS-StartPortForwardingSession --parameters '{"portNumber":["3389"],"localPortNumber":["<>"]}' --region <>
* Now, there are 2 ways to check the connectivity establishment. Firstly let us see it with Telnet to Port(3690 in this example) and Secondly via freeRDP tool to target Windows EC2
**Connect Method 1**
* Apply the telnet command to check the connection success
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pmu0wp4wwmwq9rlivdzv.png)
* Observe the connection acceptance from Session Manager port forwarded window
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2n6upqggds3027zjdech.png)
**Connect Method 2**
* Install freeRDP in source Linux EC2 Instance
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2ty9g3tc8q3195elj1zo.png)
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xbtfbmi9db8a2lb0mtvm.png)
* Run the below command to establish connection
xfreerdp /f -u administrator localhost:<>
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mi9r8vu6ii9t5jlni9hw.png)
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tup8j2rqhjpzin69hy5g.png)
Top comments (1)
I suggest auditing the “AmazonSSMManagedInstanceCore” policy and think twice before using it: it provides read access to all SSM Parameters, basically exposing it to any application on the instance that assumes a role with that policy.
It’s better to use a customized policy with minimum permissions enough for Session Manager to work.