What's a nice recipe for mounting the client's SSH_AUTH_SOCK through to the dagger workers? I'm tooling around with client: network and such but the combination of "read the SSH_AUTH_SOCK variable to get the filename, then mount that, then set the SSH_AUTH_SOCK env var on the worker side so that it matches" is just... pretty bad actually. I see references here after searching, but not a clear recipe, which is vexing some of my builds which need access to private ssh repos.
#How to nicely mount or pass-through SSH_AUTH_SOCK?
1 messages · Page 1 of 1 (latest)
(I see where you can probably mount the .ssh directory, but since buildkit allows passing through via ssh mount in docker builds, I'm assuming there's a mechanism here)
(... and I did go about mounting the .ssh directory, and it does seem to work, so this may be academic by now)
Hi, great news. That's the recommended way to interact with ssh private keys https://github.com/dagger/dagger/blob/ea275a3bafbc5b5c611e0b81bf2dd8a8add72f6b/docs/plans/docker-cli-run/ssh.cue#L14-L21
^ what Guillaume said.
If you wanna go through the ssh agent route, this should provide what you need:
package main
import (
"dagger.io/dagger"
"dagger.io/dagger/core"
)
dagger.#Plan & {
client: {
env: SSH_AUTH_SOCK: string
network: sshAgent: {
address: "unix://" + env.SSH_AUTH_SOCK
connect: dagger.#Socket
}
}
actions: {
image: core.#Pull & {
source: "alpine"
}
imageWithDocker: core.#Exec & {
input: image.output
args: ["apk", "add", "--no-cache", "openssh-client"]
}
net: client.network["unix://\(client.env.SSH_AUTH_SOCK)"].connect
verify: core.#Exec & {
input: imageWithDocker.output
env: {
SSH_AUTH_SOCK: client.env.SSH_AUTH_SOCK
}
mounts: docker: {
dest: client.env.SSH_AUTH_SOCK
contents: client.network.sshAgent.connect
}
args: ["ssh", "-o", "StrictHostKeyChecking=no", "git@github.com"]
}
}
}
Let us know if that helps!
wow... that is indeed more complex. I'll just stick with .ssh mounting for now, shall I? 🙂 But this is helpful for understanding how to do it! I have a few issues understanding how client: env and client: commands: work when sometimes it seems I need the #Nop to access the env values (particularly when chaining one command to the next), but more or less things are working...
@inner grail are you new to Dagger? We're very close to launch a preview of Cloak, a new take on allowing users to code their pipelines in their language of choice. Our initial release will support Go and typescript will follow soon after. Although CUE will still be supported, I'm bringing this in since this new upcoming release solves a lot of this pains around mounting ssh agents and better out-of-the box configs.
In any case, just wanted to bring it up since you might find it more interesting and familiar than struggling with CUE
you can check #maintainers to learn more
I am indeed new to dagger, but as we're a python shop go/typescript don't help as much as you'd think 🙂 ; I don't actually mind the struggle with cue as I'm simultaneously moving this repo away from helm charts by way of cue generation of kubernetes manifests, and cue is a very powerful and generic tool so I'm not fussed at all there--just trying to merge dagger and our existing build pipelines is throwing me.