<!--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> - [Work on this issue](https://contributors.gitlab.com/manage-issue?action=work&projectId=278964&issueIid=424737) - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=424737) </details> <!--IssueSummary end--> MR: Pending <!-- The first line of the MR must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, and the first description line of the MR should be `Issue: <Issue link with trailing +>` 3. `MR: No MR` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#1-to-1-relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description As a user, I want to be able to SSH into any workspace without having to configure it during container build time. [Why we implemented our own SSHD solution](https://about.gitlab.com/blog/2022/08/17/why-we-have-implemented-our-own-sshd-solution-on-gitlab-sass/) is a blog post by GitLab which highlights why we built our own SSHD solution. We should dogfood that. Instead of expecting users to [pre-install OpenSSH server](https://gitlab.com/gitlab-org/remote-development/gitlab-remote-development-docs/-/blob/main/doc/ssh.md) into their workspace, we should automatically inject the `sshd` into the workspace(like we do for editors/IDEs). GitLab SSHD is an [internal package of gitlab-shell](https://gitlab.com/gitlab-org/gitlab-shell/-/tree/main/internal/sshd?ref_type=heads). Can and should it be used outside of it? ### Notes - [Notes - Extending gitlab-sshd to support Remote Development - internal document](https://docs.google.com/document/d/1N_F8rY3go2KztQrHgi6qAw99E_nzAkhztSP8EeKj5lE/edit) ## Acceptance Criteria - [ ] Users no longer need to do some special configuration in their container to be able to SSH into it in a workspace. ## Technical Requirements TODO: Fill out or delete [If applicable, please list out any technical requirements for this feature/enhancement.] ## Design Requirements TODO: Fill out or delete [If applicable, please provide a link to the design specifications for this feature/enhancement.] ## Impact Assessment TODO: Fill out or delete [Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.] ## User Story TODO: Fill out or delete [Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.] <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->