You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow passing Git SSH key as an environment variable #333
Following up to a discord conversation where an user tries to clone a Git repository via SSH and is met with the following error:
envbuilder v1.0.0-rc.6+23d086e - Build development environments from repositories in a container
coder/coder#1: 🔑 Using SSH authentication!
coder/coder#1: 🔑 No SSH key found, falling back to agent!
coder/coder#1: ❌ Failed to connect to SSH agent: error creating SSH agent: "SSH agent requested but SSH_AUTH_SOCK not-specified"
coder/coder#1: 📦 Cloning git@github.com:XXX.git to /workspaces/XXX...
Failed to clone repository: clone "git@XXX.git": error creating SSH agent: "SSH agent requested but SSH_AUTH_SOCK not-specified"
Falling back to the default image...
This makes sense because the Coder user's SSH key was never added to the workspace.
While there is a workaround, it's really not great, how can we make this better?
With k8s the issue is not that bad since you can just define a secret from the key and pass that secret as a file to the container, but what about Docker and VMs?
Workaround
Downloading the key to some temporary path (via an entrypoint script, since envbox runs before the agent)
(or via the TF provider's coder_workspace_owner.ssh_* instead of using a script)
Then passing the key's path to ENVBUILDER_GIT_SSH_PRIVATE_KEY_PATH.
changed the title [-]Ability to use the Coder SSH key to clone devcontainer repositories.[/-][+]Ability to use the Coder SSH key to clone devcontainer repositories[/+]on Sep 1, 2024
For now, in the case of both Docker, the best approach is probably to write the key to a path on-disk and bind-mount it into the container. For VMs, it would be a similar process except the SSH key would have to be embedded in the VM's startup metadata. These are both probably involved enough to need their own example templates.
@phorcys420 How about adding ENVBUILDER_GIT_SSH_PRIVATE_KEY_BASE64 for the use-case where writing the key to a file isn't an easy option? I'd like to keep the file option around because some security-conscious orgs don't like having secrets stored in environment variables.
For now, in the case of both Docker, the best approach is probably to write the key to a path on-disk and bind-mount it into the container.
I think this isn't great because it requires an additional step in the Terraform template, in this case they use the user's SSH key, which means storing each user's key then mounting it.
@phorcys420 How about adding ENVBUILDER_GIT_SSH_PRIVATE_KEY_BASE64 for the use-case where writing the key to a file isn't an easy option? I'd like to keep the file option around because some security-conscious orgs don't like having secrets stored in environment variables.
I think this is a fine workaround given that even if we don't like storing secrets in environment variables, the Coder agent token is stored in the env and allows to get the private key, so no downgrade in terms of security.
I agree, the file option should stay too.
Reacted by Cian Johnston, Atif Ali and Mark Percival
changed the title [-]Ability to use the Coder SSH key to clone devcontainer repositories[/-][+]Allow passing Git SSH key as an environment variable[/+]on Sep 2, 2024
Hey,
Not sure I'm using the right issue or if I should create a new one, but I ended up here after following this and this.
So I'm trying to spin up some workspaces in K8S using some .devcontainers on a remote public gitlab repository that require authentication. As of now, I'd like to use the ssh key provided to the user within his profile to access this repository. In my case my Coder instance is setup to use OIDC from a local Keycloak instance.
My understanding is that envbuilder can do this, if you provide a path to private key file or use SSH_AUTH_SOCK. And I'm suppose to use the first option in a Kubernetes context.
However, because its a file that is expected, am I suppose to create a new kubernetes secret from my template that would get details from coder_workspace_owner.private_ssh_key ?
I've tried to do exactly this modifying the default .devcontainer template for K8S to retrieve the owner private key to generate a secret and mount it as a file for envbuilder to use. However, by default the RBAC role cannot create new secret in the coder namespace.
Am I missing something here or is it the current way to go and I need to grant more rights to my role? Also, this sounds like a workaround as it makes the users ssh key appear in my K8S "secrets"
Activity
[-]Ability to use the Coder SSH key to clone devcontainer repositories.[/-][+]Ability to use the Coder SSH key to clone devcontainer repositories[/+]johnstcn commentedon Sep 2, 2024
Linking a relevant PR here: #174
For now, in the case of both Docker, the best approach is probably to write the key to a path on-disk and bind-mount it into the container. For VMs, it would be a similar process except the SSH key would have to be embedded in the VM's startup metadata. These are both probably involved enough to need their own example templates.
johnstcn commentedon Sep 2, 2024
@phorcys420 How about adding
ENVBUILDER_GIT_SSH_PRIVATE_KEY_BASE64for the use-case where writing the key to a file isn't an easy option? I'd like to keep the file option around because some security-conscious orgs don't like having secrets stored in environment variables.phorcys420 commentedon Sep 2, 2024
I think this isn't great because it requires an additional step in the Terraform template, in this case they use the user's SSH key, which means storing each user's key then mounting it.
phorcys420 commentedon Sep 2, 2024
I think this is a fine workaround given that even if we don't like storing secrets in environment variables, the Coder agent token is stored in the env and allows to get the private key, so no downgrade in terms of security.
I agree, the file option should stay too.
[-]Ability to use the Coder SSH key to clone devcontainer repositories[/-][+]Allow passing Git SSH key as an environment variable[/+]2o1o0 commentedon Oct 7, 2024
Hey,
Not sure I'm using the right issue or if I should create a new one, but I ended up here after following this and this.
So I'm trying to spin up some workspaces in K8S using some .devcontainers on a remote public gitlab repository that require authentication. As of now, I'd like to use the ssh key provided to the user within his profile to access this repository. In my case my Coder instance is setup to use OIDC from a local Keycloak instance.
My understanding is that envbuilder can do this, if you provide a path to private key file or use SSH_AUTH_SOCK. And I'm suppose to use the first option in a Kubernetes context.
However, because its a file that is expected, am I suppose to create a new kubernetes secret from my template that would get details from
coder_workspace_owner.private_ssh_key?I've tried to do exactly this modifying the default .devcontainer template for K8S to retrieve the owner private key to generate a secret and mount it as a file for envbuilder to use. However, by default the RBAC role cannot create new secret in the coder namespace.
Am I missing something here or is it the current way to go and I need to grant more rights to my role? Also, this sounds like a workaround as it makes the users ssh key appear in my K8S "secrets"
Thanks!
johnstcn commentedon Oct 10, 2024
That's correct. If you're using the Helm chart, you can add the required roles and roleBindings to
extraTemplatesin yourvalues.yaml.Correct, this issue would be the actual fix!
johnstcn commentedon Oct 25, 2024
Created a follow-up issue for the provider: coder/terraform-provider-envbuilder#58
mwiede commentedon Mar 14, 2025
stumbling in here and got it running with
"ENVBUILDER_GIT_SSH_PRIVATE_KEY_BASE64": base64encode(data.coder_workspace_owner.me.ssh_private_key)supanadit commentedon Jun 7, 2025
Wow that's work, why is that not included in the template... weirds...