bug: ISSUE-7452: Fix EC2 Workspace Connect for Any OS

[arminanton]

Problem

Described at #7452

Solution

• Changed sed call to a generic style that works in any platform.
• Removed the OS constrains to use string instead, and added the option to provide custom user name in cases where not standard OS is in use.
• Still pending option for ECS remote workspace connect for Tasks, similar to what we have for EC2 instances.

Notes

• Same existing tests in place should work. (FAILED, working on that)

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

• This pull request modifies code in src/* but no tests were added/updated.
  • Confirm whether tests should be added or ensure the PR description explains why tests are not required.

[arminanton]

Might need to change a bit here since now we have an input/prompt when the OS does not match Amazon Linux or Ubuntu.

[arminanton]

Tested the stable vsix generated and worked fine.

Prompt of the user desired to be used:

Tested ssm-user and it failed, which is the user we use to usually access the terminal in AWS Toolkit for EC2 instances. Then, I tried another user that we use for testing our running services in the instance, and it worked:

One thing I did noticed though is that it connected to / directly instead of asking which path it wanted to connect, or instead of using /home/${user} as default path.

I also noticed that the connection is not that steady, it loses connection after a few seconds being connected to the instance, and suggests to reload the window (just like a connection lost). I suspect it might be because we are in / and it might be trying to sync or analyze all the files and projects present.

Not sure if we need to do anything else to keep it more steady.

When I try to connect using regular ssm user like ssm-user it gives me this error in logs:

2025-06-09 15:25:17.940 [warning] ec2: failed to clean keys: 'Error: Failed in sending command to target i-1234567890abcdefg\n' +
  `\t -> Error: {"state":"FAILURE","reason":{"$metadata":{"httpStatusCode":200,"requestId":"(...)","attempts":1,"totalRetryDelay":0},"CloudWatchOutputConfig":{"CloudWatchLogGroupName":"","CloudWatchOutputEnabled":false},"CommandId":"(...)","Comment":"","DocumentName":"AWS-RunShellScript","DocumentVersion":"$DEFAULT","ExecutionElapsedTime":"PT0.005S","ExecutionEndDateTime":"2025-06-09T22:25:12.570Z","ExecutionStartDateTime":"2025-06-09T22:25:12.570Z","InstanceId":"i-1234567890abcdefg","PluginName":"aws:runShellScript","ResponseCode":2,"StandardErrorContent":"sed: can't read /home/ssm-user/.ssh/authorized_keys: No such file or directory\\nfailed to run commands: exit status 2","StandardErrorUrl":"","StandardOutputContent":"","StandardOutputUrl":"","Status":"Failed","StatusDetails":"Failed"},"observedResponses":{"200: OK":2}}`
2025-06-09 15:25:23.910 [error] aws.ec2.openRemoteConnection: Error: Failed in sending command to target i-1234567890abcdefg
	 -> Error: {"state":"FAILURE","reason":{"$metadata":{"httpStatusCode":200,"requestId":"(...)","attempts":1,"totalRetryDelay":0},"CloudWatchOutputConfig":{"CloudWatchLogGroupName":"","CloudWatchOutputEnabled":false},"CommandId":"(...)","Comment":"","DocumentName":"AWS-RunShellScript","DocumentVersion":"$DEFAULT","ExecutionElapsedTime":"PT0.003S","ExecutionEndDateTime":"2025-06-09T22:25:18.557Z","ExecutionStartDateTime":"2025-06-09T22:25:18.557Z","InstanceId":"i-1234567890abcdefg","PluginName":"aws:runShellScript","ResponseCode":1,"StandardErrorContent":"/var/lib/amazon/ssm/i-1234567890abcdefg/document/orchestration/(...)/awsrunShellScript/0.awsrunShellScript/_script.sh: line 1: /home/ssm-user/.ssh/authorized_keys: No such file or directory\nfailed to run commands: exit status 1","StandardErrorUrl":"","StandardOutputContent":"","StandardOutputUrl":"","Status":"Failed","StatusDetails":"Failed"},"observedResponses":{"200: OK":2}}

From this log, we can extract sed: can't read /home/ssm-user/.ssh/authorized_keys: No such file or directory\\nfailed to run commands: exit status 2, which means that the file or folder does not exist.

Out of curiosity, I tried using root user, like it is done for ECS tasks, and it returned the same error than ssm-user. Perhaps what is missing is to properly setup the /home/${user}/.ssh/authorized_keys for these said chosen users, which will then make it succeed as desired.

[justinmk3]

Perhaps what is missing is to properly setup the /home/${user}/.ssh/authorized_keys for these said chosen users

That's definitely an important part of the logic.

it connected to / directly instead of asking which path it wanted to connect, or instead of using /home/${user} as default path.

It looks like we always tell vscode to choose / as the target dir:

aws-toolkit-vscode/packages/core/src/awsService/ec2/model.ts

Lines 215 to 218 in d8d08e2

	await startVscodeRemote(
	remoteEnv.SessionProcess,
	remoteEnv.hostname,
	'/',

I think we depend on some later step to detect $HOME, or something like that.

[arminanton]

I think we depend on some later step to detect $HOME, or something like that.

We might want to double check that logic, as we aren't required to specify any path when connecting vscode to an instance.
Like, if I add a new host manually to vscode and use remote ssh to connect to it, it would connect to the instance without having any path open at all. That saves us from vscode attempts to explore all paths generically (as it assumes / as a regular project folder).
Perhaps that path parameter in the actual caller is optional.

For the ssh authorized keys, might want to explore and improve this part:

https://github.com/aws/aws-toolkit-vscode/blob/master/packages/core/src/awsService/ec2/model.ts#L321-L336

Unit Tests failed: https://d1ihu6zq92vp9p.cloudfront.net/0df37705-e8d7-47be-b4ea-52e36cb34a6c/report.html

I saw the errors reported from the unit test run. I will work on them and push a fix soon.

ECS portion

In the meantime, if anyone wants to explore the option to connect ECS to vscode.