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

Remote Workspaces #1432

Open
DarkGhostHunter opened this issue Nov 29, 2024 · 5 comments
Open

Remote Workspaces #1432

DarkGhostHunter opened this issue Nov 29, 2024 · 5 comments

Comments

@DarkGhostHunter
Copy link

DarkGhostHunter commented Nov 29, 2024

Is your feature request related to a problem?

Basically allow a computer from the same network (or remotely) to connect to a DevContainer of another computer.

Which solution do you suggest?

Expose a port in the 22222~22299 range. DevPod could show SSH config to copy & paste into the client so it can connect through the CLI like ssh my-remote.devpod.

This makes opening an SSH port in the target computer totally optional, and bypasses the host.

Which alternative solutions exist?

None that is easy to setup.

Additional context

@DarkGhostHunter DarkGhostHunter changed the title Remote connection from another computer Remote Workspaces Nov 29, 2024
@bkneis
Copy link
Contributor

bkneis commented Dec 16, 2024

Hi @DarkGhostHunter thanks for reporting your use case. I'm a little unsure what you want to achieve as from the sounds of it devpod already does this. When you up a workspace, you can ssh into it via ssh {workspace}.devpod. Workspaces can be deployed locally or remotely using something like the docker or ssh provider.

@DarkGhostHunter
Copy link
Author

DarkGhostHunter commented Dec 16, 2024

It uses SSH but via stdio. You can't connect to the devpod outside the network, because the agent inside the container doesn't expose a network connection for SSH.

Plus, for some reason It's hardcoded.

@bkneis
Copy link
Contributor

bkneis commented Dec 16, 2024

@DarkGhostHunter I'm not sure what the issue is asking for, can you please clarify what you want changed in devpod? Devpod can connect to remote workspaces outside of the network as that is what is was built for :) The STDIO used by the SSH client is tunnelled through a provider that can connect to workspaces remotely, such as the kubernetes provider.

Can you tell me more about your workflow and what you tried and what didn't work?

@DarkGhostHunter
Copy link
Author

DarkGhostHunter commented Dec 16, 2024

@DarkGhostHunter I'm not sure what the issue is asking for, can you please clarify what you want changed in devpod? Devpod can connect to remote workspaces outside of the network as that is what is was built for :) The STDIO used by the SSH client is tunnelled through a provider that can connect to workspaces remotely, such as the kubernetes provider.

Can you tell me more about your workflow and what you tried and what didn't work?

 ┌──────────────┐  ┌─────────────┐
 │ ┌──────────┐ │  │             │
 │ │          │ │  │             │
 │ │  DevPod  ◄─┼──┼             │
 │ │          │ │  │             │
 │ └──────────┘ │  │             │
 │              │  │             │
 │     PC-1     │  │     PC-2    │
 │              │  │             │
 └──────────────┘  └─────────────┘

https://darkghosthunter.medium.com/developing-on-a-local-remote-devcontainer-d282b7837bf9

Our luck runs short immediately because this command is hardcoded. In other words, the command that creates the SSH Server in the container cannot be configured and it will always use stdin. Heresy!

@bkneis
Copy link
Contributor

bkneis commented Dec 17, 2024

@DarkGhostHunter thank you for linking to the blog post, that clarified a lot. Currently devpod does not natively support this but this is definitely a cool feature we would like to add in the future so I'll leave this open! Or if you wanted to contribute it we would be happy to review :) The reason we hard code the SSH server is since this is only expected to run with a provider that establishes an "outer tunnel" for the SSH tunnel. Since workspaces are often not addressable we need to pipe the SSH server through the STDIO of the provider tunnel. I thought your solution was creative and if you needed to access from other machines should work despite the mentioned drawbacks.

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

No branches or pull requests

2 participants