Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(toolkit): attach lifetime to generated ssh keys. #5578

Merged
merged 217 commits into from
Sep 20, 2024

Conversation

Hweinstock
Copy link
Contributor

@Hweinstock Hweinstock commented Sep 12, 2024

Problem

For connecting VSCode to EC2 instance, we generate an ssh key pair on disk. This results in writing the private ssh key to VSCode global storage, allowing the key to be potentially reused by other users on the same machine.

Solution

Attach a lifetime to any key pair generated such that they wipe from disk after X seconds. Value is currently set is 30 seconds to allow connection to reliably establish. Also, change file permissions to read/write owner only and change behavior to overwrite existing keys.

Unable to test file permissions, due to VSCode file system unable to provide us with enough detail. Only provides whether it is readonly or not (somewhat unreliably: microsoft/vscode-discussions#673). VSCode file system is what is used in fs.ts implementation.

This is in-line with how ec2 instance connect works: https://github.com/aws/aws-ec2-instance-connect-cli/blob/master/ec2instanceconnectcli/EC2InstanceConnectKey.py


License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

Hweinstock and others added 30 commits July 7, 2023 14:03
Base automatically changed from hkobew/ec2/useActions to master September 19, 2024 17:20
Copy link

This pull request implements a feature or fix, so it must include a changelog entry. See CONTRIBUTING.md#changelog for instructions.

@Hweinstock Hweinstock marked this pull request as ready for review September 19, 2024 18:40
@Hweinstock Hweinstock requested a review from a team as a code owner September 19, 2024 18:40
@justinmk3
Copy link
Contributor

Attach a lifetime to any key pair generated such that they wipe from disk after X seconds. Value is currently set is 30 seconds to allow connection to reliably establish. Also, change file permissions to read/write owner only and change behavior to overwrite existing keys.

Great idea. Would also be a good time to add a EC2-specific section here:

## Remote connect

That way, we have a high-level description of the steps that happen.

@@ -5,19 +5,32 @@
import * as fs from 'fs-extra'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's not much trouble, it would be helpful to remove this and use our fs.ts module instead. We want to eliminate 'fs-extra'

Copy link
Contributor Author

@Hweinstock Hweinstock Sep 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn't figure out how to set file permission (fs.chmod equivalent) through fs.ts. While ssh-keygen seems to do this for me locally, it fails in CI without this. Should I keep fs-extra for this until a chmod equivalent exists in fs.ts?

Copy link
Contributor

@justinmk3 justinmk3 Sep 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how to set file permission (fs.chmod equivalent) through fs.ts

would you mind adding a stub for chmod in fs.ts? it can just do nothing for if (isWeb()). and for non-web, it can use node's chmod (from 'fs', instead of 'fs-extra)

this could be a followup PR. for now in this PR, if it's easy, try using 'fs' instead of 'fs-extra'.

@Hweinstock
Copy link
Contributor Author

/retryBuilds


public async delete(): Promise<void> {
await fs.delete(this.publicKeyPath)
await fs.delete(this.keyPath)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might be a good idea to delete the private key first, in case deleting the public key fails (which is less important)

@Hweinstock Hweinstock merged commit 24840fd into master Sep 20, 2024
23 of 24 checks passed
@Hweinstock Hweinstock deleted the hkobew/ec2/noDiskKey branch September 20, 2024 18:52
}

public isDeleted(): boolean {
return this.deleted
Copy link
Contributor

@justinmk3 justinmk3 Sep 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this extra state be avoided? usually better to check "reality", i.e. check the filesystem. after all, we're already storing the filepath.

intermediate state can drift, and leads to "coherency" bugs. even very simple state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So in that case, replace the isDeleted() method with one that checks the actual filesystem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants