OK... how to handle `--mount=type=ssh` in Dockerfiles within dagger?

[safe tendon]

I finally figured out why some builds were taking forever--they were relying on a private git repo, and our dockerfiles were using --mount=type=ssh. I was mounting my .ssh directory into the dagger task container just fine, but while I can't see the output, I'm pretty sure that it's sitting there waiting for me to type my passphrase.

Now, our old build process was using ssh-agent, and we can probably manage that but the passthrough described elsewhere for SSH_AUTH_SOCK was a little cosmic. The way to interact by mounting .ssh (https://github.com/dagger/dagger/blob/ea275a3bafbc5b5c611e0b81bf2dd8a8add72f6b/docs/plans/docker-cli-run/ssh.cue#L14-L21) doesn't look like it handles keys with passphrases.

I'm old-fashioned enough to want passphrases; is the SSH_AUTH_SOCK route the only way to handle this?

(this is for a docker.#Run command which then uses a build tool to build from a dockerfile which internally has a mount=type=ssh)

[safe tendon]

(well, the ssh_auth_sock route actually did work, but it is somewhat more painful than I'd prefer. Still... it makes sense, just a mite confusing)

[coral hinge]

Hi,
We are currently relying on the ssh-agent for git clones https://github.com/dagger/dagger/blob/4f29d2d35d7b48efee9aadd009d62acf7bf840c7/core/core.schema.go#L86-L88.

What build tool do you use ? What does the operation look like ?
You do not rely on docker.#BuildI presume ?

Because, we're using docker's frontend for docker.#Build operations, but I don't know if it automatically retrieves that instruction or if we shall still pass it

[safe tendon]

Ah, sure. No, I'm using the pants build tool (which itself runs docker) from within docker.#Run... forwarding the SSH_AUTH_SOCK manually does do the trick (mostly).

[coral hinge]

@warm fern would it make sense/ do you see any security concern to also forward the ssh-agent inside our core.build to accept Dockerfiles relying on mount=type=ssh. Also to core.run, as some users apparently rely on other build tools (pants) ?

I can create the issue and corresponding PR, if you think it's valuable

[warm fern]

I think we should support that, but it should probably be opt in rather than a default. Definitely worth an issue

[split roost]

👋 I recall coming across this in the past. Definitely the keyPassphrase was something pending to implement (https://github.com/dagger/dagger/blame/v0.2.36/pkg/universe.dagger.io/docker/cli/client.cue#L48. Maybe we can revisit it for the dagger-cue refactor? cc @molten goblet

[molten goblet]

Yeah, that's something we could consider... that said, I don't think v0.3 allows mounting of sockets yet, so that'd be a blocker to using this with the new code.

[split roost]

I see... so dagger.#Socket is still not a thing in 0.3 yet? Having said that, the keyPassphrase apparoach could be added as a secret, correct?

[molten goblet]

Yes to dagger.#Socket not being a thing.

Yes, it's possible to the keyPassphrase approach. I haven't been spending any time improving v0.2, however.

[coral hinge]

Do we really need to mount the socket ?
As we are already relying on this feature for git, we just need a way to specify to these core build operations that this llb.MountSSHSock forward was requested, and, if true, add this llb operation. Issue created: https://github.com/dagger/dagger/issues/3581

[molten goblet]

We could change v0.2 to do this, yes. But I'm currently focused on getting the v0.2 API implemented on the v0.3 engine, which will require some way to mount sockets.

[coral hinge]

I might have misunderstood something then 😇 From my perspective, all we have to do (in v0.3 engine), is to add this llb operation as an ops, and Buildkit would automatically forward the ssh connection to the container: it would 1) automatically forward it to the dockerfile.v0 ; 2) be the same for the run operation. We already do that for the v0.3 core.git operation. I don't see why the socket mount is required here, but it is probably a lack of vision on my side 😇