-
Notifications
You must be signed in to change notification settings - Fork 295
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
Dotfiles cloned before ssh-agent is started #1034
Comments
@martinbiard Thanks for opening the issue - fair point, we'll look into it. |
This looks like another one that I recently fixed here: #1008. |
@martinbiard could you try this with the new v0.5.6 release please? |
Actually, the v0.5.6 pre-release is crashing really early in the build, it doesn't make it to the dotfiles part. This is from an exact setup that works on v0.5.5. I tried without anything in the Customizations > Dotfiles, and same error. I had tried a v0.5.6-alpha a few days ago and I was also getting this error back then. It seems to be trying to get a pre-build image even though i didn't enter anything:
Full debug logs of the build:
|
@martinbiard I see, thanks. Is |
@pascalbreuninger No, it's writeable. |
So I think the issue is related to the slashes used in the path. Golang more often than not required os-specific usage. So I suspect initially that the |
@shanman190 Oh I missed that! Good find |
#1042 might fix this |
@martinbiard Can you try again with this prelease please? |
@pascalbreuninger Still same issue, unfortunately. Version 0.5.7-10 Logs:
|
Encountering the same issue too, it prevents using newer versions (0.5.5 is latest working) on Windows. It seems to be related to this PR #1008 |
@siccous, are you also expecting to be using the OpenSSH for Windows distribution (ie. The one that ships with Windows itself or a newer version via PowerShell/Win32-OpenSSH)? @martinbiard and @siccous, what version of SSH are you folks using? |
I've tried this test using the loft-sh/devpod repo and my personal dotfiles on... OS: Windows 10 Home For my test both the main devcontainer repo cloned successfully, my dotfiles cloned successfully, and my dotfiles failed to install due to interactive prompts as I expected for this environment. |
This also works on my Windows 10 Enterprise machine, but my docker desktop is broken there, so instead I'm using the AWS provider. |
OpenSSH version: I think this issue went from being about dotfiles to being completely broken on Windows from v0.5.6 so I can't actually test the new dotfiles features. Personally, I'm still stuck on v0.5.5 and unable to upgrade due to above issue. |
@martinbiard, would you be willing to upgrade your OpenSSH installation by following the guide here? What I'm pretty sure is the issue is that the source (OpenSSH 8.9) and the target (likely 9.x) are incompatible from an ssh-agent forwarding standpoint. |
@shanman190 I actually had the latest v9.x before and downgraded it to v8.9, last of 8.x because all the v9.x have a note saying "This is a beta-release (non-production ready)" while the v8.x don't have this note. I'll give it a try on 9.5 though. |
@shanman190 So yeah, still same issue: Versions: Docker provider Logs:
|
Found the issue, it's caused by ssh mount https://docs.docker.com/build/building/secrets/#ssh-mounts Both me and Martin are using this feature in our build, if you remove it then it works. @shanman190 you should be able to reproduce it now. |
@shanman190 Ok I did some more testing and found that, if I use a devcontainer image directly in the devcontainer.json it does work, but in my case I'm actually using the build my own image that extends from one of the official devcontainer images. So, this config works:
While this one doesn't:
Dockerfile:
|
I can confirm, simply removing this from my config allows the build to proceed without error: |
Just to check, what docker distribution and version are you all using from a local provider? I just want to make sure that I'm covering my base on that side as well. |
Docker version: 26.0.0, build 2ae903e (WSL2 integration through Docker Desktop) |
Versions: |
@martinbiard, so the option @siccous, are you performing a Git SSH clone within your Dockerfile and thus would be actually using the SSH forwarding into the Docker build? As to what appears to be the root cause of the issues is that the ssh-server helper for the docker path is started on the source machine expecting a unix like environment. The ssh server code on the other hand doesn't know how to handle the proxying to the Windows pipe, unlike the core devpod process. Since the docker build is happening from within the agent process tree, this means that it inherits the SSH_AUTH_SOCK environment variable which points to the listener socket that the SSH server establishes. Due to the Windows pipe though, this socket ends up at a dead end. Docker buildx has knowledge about how to natively use the Windows socket which you can enable with the As I see it, there are probably two options to actually solve the issue of allowing the SSH agent within the Docker build itself:
@pascalbreuninger, any opinions here? |
@shanman190 I see, thanks for investigating. I didn't really follow the discussion earlier and wasn't aware the build arg As for the solutions
This relies on docker actually handling the windows forwarding and as drop-in-replacements (podman, orbstack, colima) become more common I wouldn't rely on all of these third party binaries to handle it correctly, so
Seems to be the way to go |
@shanman190 You are right, in my case it's not needed, it was a remnant. Previously, I tried Jetbrains Gateway directly without DevPod and Gateway was doing a shallow git checkout so inside my container I didn't have a properly setup git repository to work with and I was force to re-clone inside the devcontainer which is why I was needing the SSH agent forwarding at build-time. |
Yes in my case it is needed, we are cloning some internal repos through SSH during the build. |
What happened?
I tried to use the dotfiles feature. I prefer to keep my dotfiles repository private, so SSH authentication needs to work in the devcontainer before the dotfiles repository can be cloned. Here is part of debug log relating to this issue:
What did you expect to happen instead?
I expected dotfiles repository to be successfully cloned, regardless of if the repository is public or private.
How can we reproduce the bug? (as minimally and precisely as possible)
Create a private dotfiles repository and try to set it up in devpod.
Local Environment:
DevPod Provider:
The text was updated successfully, but these errors were encountered: