Summary
Let users SSH into their sandbox from a local terminal, enabling use of local editors and tools.
User stories
- "I want to use my local VS Code / Neovim connected to the sandbox via SSH"
- "I want to
scp files in/out of my sandbox"
- "I want to use my local terminal instead of the browser"
Approaches (pick one)
1. kubectl exec proxy (simplest)
- Add an API endpoint that proxies SSH-like access through the server
- Users connect via a CLI tool or
ssh with ProxyCommand
- No changes to container image needed
- Leverages existing K8s exec infrastructure
2. SSH bastion on server pod
- Run sshd on the remolt server pod
ssh {session-id}@remolt.dev → server does kubectl exec into the sandbox
- Clean UX, single entry point
- Need to manage SSH key injection (from GitHub profile or upload)
3. Tailscale/WireGuard sidecar
- Add Tailscale sidecar to sandbox pods
- Users join the same tailnet and SSH directly
- Most polished, supports VS Code Remote SSH natively
- Most complex to set up
4. Direct sshd in pods
- Install sshd in container, expose via NodePort/LoadBalancer
- Inject user's SSH key during pod creation (fetch from GitHub API)
- Simple but hard to manage ports at scale
Considerations
- Network policy currently blocks all pod ingress except from server pod
- Auth: SSH keys from GitHub profile (
https://github.com/{user}.keys) would be seamless
- VS Code Remote SSH compatibility is a big draw
- Security: sandboxes already have sudo, SSH doesn't change the threat model
Summary
Let users SSH into their sandbox from a local terminal, enabling use of local editors and tools.
User stories
scpfiles in/out of my sandbox"Approaches (pick one)
1. kubectl exec proxy (simplest)
sshwith ProxyCommand2. SSH bastion on server pod
ssh {session-id}@remolt.dev→ server doeskubectl execinto the sandbox3. Tailscale/WireGuard sidecar
4. Direct sshd in pods
Considerations
https://github.com/{user}.keys) would be seamless