How to connect to a private EC2 instance from a local Visual Studio Code IDE with Session Manager and AWS SSO (CLI)
Easily and securely develop on private EC2 instances from a local VS Code
In this article, I show you how to connect your local VS Code IDE to an EC2 instance that is running in a private subnet by using AWS Systems Manager Session Manager and AWS Single Sign-On (SSO).
This is useful when you want to benefit from the capabilities of EC2 instances, while having consistent rich development experience. Because we use Session Manager here, no public access to the EC2 instance is needed.
Prerequisites
- AWS CLI
- AWS CLI configured to use AWS SSO
- An EC2 instance that you can already connect to using Session Manager (see Session Manager prerequisites if this is the first time using Session Manager)
- Session Manager plugin for AWS CLI
- VS Code Remote Development extension
Method
The following steps are tested on Mac. Similar process should work on other Operating Systems.
-
Add the following lines into your
~/.ssh/configfile.
Replace thei-00aa22bb33cc44dd5with your EC2 instance ID. Replace the<SSO_PROFILE_NAME>and<REGION>with the actual values.Host i-00aa22bb33cc44dd5 User ec2-user ProxyCommand sh -c "aws sso login --profile <SSO_PROFILE_NAME>; export AWS_PROFILE=<SSO_PROFILE_NAME>; export AWS_REGION=<REGION>; aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'" -
On VS Code, "Open a Remote Window" as shown in the following images.
-
This opens your default browser and begins the login process for your AWS SSO account, the typical way when using AWS CLI with SSO.
Follow the steps on your browser to Allow the Authorize request.- If the connection failed (timeout), it can be due to a long delay when you are going through the browser flow to Allow the Authorize request. In this case, simply click on Retry and Allow the request on browser again (shown below).
- If the connection failed (timeout), it can be due to a long delay when you are going through the browser flow to Allow the Authorize request. In this case, simply click on Retry and Allow the request on browser again (shown below).
-
You should now be connected to the EC2 and be able to open folders on EC2 the same way you do for your local code.
Enjoy coding!
Nice solution :)
Good article
Don't you need a pem file for the keys to your instance?
Does it work without the pem file?
So I did all this but have a "Could not establish connection to "i-xxxxxxxxxx": Permission denied (publickey,gssapi-keyex,gssapi-with-mic)." on both Ubuntu and AL2. My instance is in a public net with an IPv4, and has no pem key. What is wrong?
Unfortunately, it is not working. I experienced same case as @Olivier.. This article should provide additional guide. :(
So I did all this but have a "Could not establish connection to "i-xxxxxxxxxx": Permission denied (publickey,gssapi-keyex,gssapi-with-mic)." on both Ubuntu and AL2. My instance is in a public net with an IPv4, and has no pem key. What is wrong?
This, (like many blog posts) leaves steps out or glosses over them. This one leaves out that you have to create and use a pem key with this mechanism. You must also be using working profiles or your remote-ssh session won't be able to connect to aws. I was using the copy/paste method from AWS SSO and had to figure out aws sso configure and how to use it to set up a profile.
This blog has a bunch of stuff I didn't need, but it was more complete https://aws.amazon.com/blogs/architecture/field-notes-use-aws-cloud9-to-power-your-visual-studio-code-ide/
Good, comprehensive guide. But indeed, the part where you add the Key file to the ssh config is missing. Update the ~/.ssh/config by adding an IdentityFile with a reference to the key file like this:
Host i-00aa22bb33cc44dd5
User ec2-user
ProxyCommand sh -c "aws sso login --profile <SSO_PROFILE_NAME>; export AWS_PROFILE=<SSO_PROFILE_NAME>; export AWS_REGION=<REGION>; aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
IdentityFile "~/.ssh/MyPrivateKey.pem"
Also, make sure the key has the right (restrictive) permissions in order for it to be usable by SSH, by first running
chmod 600 ~/.ssh/MyPrivateKey.pem
