<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=502950) </details> <!--IssueSummary end--> <!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.--> ### Proposal <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> GitLab Workspaces currently supports remote SSH access to a workspace. The primary use I (and my users) see for this is so that they can use VSCode on their Windows laptop, but have access to an environment running Linux (the workspace). Users prefer the permanence, customisation and performance of native VSCode over the browser version in Workspaces. Currently, the workflow looks like this: 1. Provision a Workspace via the GitLab UI 2. Connect to the Workspace using the "Remote - SSH" VSCode extension 3. Enter the Personal Access Token (PAT). Enter it again when VSCode prompts for it a 2nd time (not sure why) 4. Clone the project of interest to the Workspace 5. Open the project in VSCode 6. Enter the Personal Access Token (PAT). Enter it again when VSCode prompts for it a 2nd time (not sure why) 7. Do development As a user I've been having to keep a Notepad document with my PAT on hand so that I can enter it as VSCode prompts for it anytime a new project is opened, and sometimes randomly. It's very annoying and obviously a security issue waiting to happen. If GitLab Workspaces switched to public-key SSH authentication, the workflow could instead be: 1. Provision a Workspace via the GitLab UI 2. Connect to the Workspace using the "Remote - SSH" VSCode extension 4. Clone the project of interest to the Workspace 5. Open the project in VSCode 7. Do development #### Technical implementation Currently the `gitlab-workspaces-proxy` uses the [user-self-lookup API](https://gitlab.com/gitlab-org/workspaces/gitlab-workspaces-proxy/-/blob/main/pkg/gitlab/user.go?ref_type=heads#L13) to figure out the ID of the calling user so that it can do the basic "are you allowed to access this specific workspace" check. Instead, the proxy could use an API like the ["Get user by fingerprint of SSH key"](https://docs.gitlab.com/ee/api/keys.html#get-user-by-fingerprint-of-ssh-key) API to figure out the ID of the calling user based off of the public key that they present. This endpoint is only available to administrators, but hopefully it gets the point across. <!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section. --> <!-- Label reminders Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ -->