Problem
The docker provider hardcodes root as the seeded SSH user in the container. create_vm sends only DRUKBOX_AUTHORIZED_KEY and DRUKBOX_ENV_KEYS into the container (src/providers/docker/provider.py), and images/local/entrypoint.sh writes the key to /root/.ssh/authorized_keys. The ssh_username setting only names the account callers connect as — it never reaches the entrypoint.
A downstream image that needs the key seeded for a non-root user must replace the whole entrypoint. druks does exactly this: its sandbox image carries a near-copy of images/local/entrypoint.sh whose only real difference is seeding /home/druks instead of /root (agents there must SSH in unprivileged because Claude Code refuses --permission-mode bypassPermissions as root). The copy re-implements the env loop, host-key generation, and the sshd exec, and drifts silently when the base entrypoint changes.
Fix
Tell the container which user to seed:
- The docker provider passes its
ssh_username setting into the container as a third env var (for example DRUKBOX_SSH_USERNAME), next to DRUKBOX_AUTHORIZED_KEY and DRUKBOX_ENV_KEYS.
images/local/entrypoint.sh seeds that user's ~/.ssh/authorized_keys with the correct ownership, defaulting to root when the variable is absent so existing images and callers keep working.
The docker-sbx provider is unaffected: its bootstrap already targets the configured user over the exec channel.
Outcome
A derived image with a non-root SSH user reduces to base + its own layers + useradd — no entrypoint override. druks can then delete its deploy/sandbox/entrypoint.sh and run the stock base entrypoint with DOCKER_SSH_USERNAME=druks.
Problem
The docker provider hardcodes root as the seeded SSH user in the container.
create_vmsends onlyDRUKBOX_AUTHORIZED_KEYandDRUKBOX_ENV_KEYSinto the container (src/providers/docker/provider.py), andimages/local/entrypoint.shwrites the key to/root/.ssh/authorized_keys. Thessh_usernamesetting only names the account callers connect as — it never reaches the entrypoint.A downstream image that needs the key seeded for a non-root user must replace the whole entrypoint. druks does exactly this: its sandbox image carries a near-copy of
images/local/entrypoint.shwhose only real difference is seeding/home/druksinstead of/root(agents there must SSH in unprivileged because Claude Code refuses--permission-mode bypassPermissionsas root). The copy re-implements the env loop, host-key generation, and the sshd exec, and drifts silently when the base entrypoint changes.Fix
Tell the container which user to seed:
ssh_usernamesetting into the container as a third env var (for exampleDRUKBOX_SSH_USERNAME), next toDRUKBOX_AUTHORIZED_KEYandDRUKBOX_ENV_KEYS.images/local/entrypoint.shseeds that user's~/.ssh/authorized_keyswith the correct ownership, defaulting to root when the variable is absent so existing images and callers keep working.The docker-sbx provider is unaffected: its bootstrap already targets the configured user over the exec channel.
Outcome
A derived image with a non-root SSH user reduces to base + its own layers +
useradd— no entrypoint override. druks can then delete itsdeploy/sandbox/entrypoint.shand run the stock base entrypoint withDOCKER_SSH_USERNAME=druks.