DevWorkspace doesn't respect SSH key passphrase when git pushing changes from workspace about devworkspace-operator HOT 7 OPEN

@AObuchow I believe that the problem is in the DWO side indeed. From the recording we see that the git push command called from terminal invokes the default ssh-askpass tool. Looks like we need to propagate the ssh-askpass.sh script to the workspace container as well.

from devworkspace-operator.

@vinokurig, here are some thoughts on where in the codebase we could make the required changes:

• We could inject the required DISPLAY & SSH_ASKPASS environment variables to the workspace containers in /pkg/library/env/workspaceenv.go. A new function (something like addSSHEnvironmentVariables()) could be made to inject these environment variables, or we could potentially use the commonEnvironmentVariables() function.
• The code related to injecting ssh-askpass.sh into the workspace containers could probably be added in its own file in /pkg/provision/, e.g. /pkg/provision/ssh/. Alternatively, it could go into /pkg/provision/workspace/.
  • You will probably have to call your function that injects ssh-askpass.sh in the main reconcile function (unless there's a better place for this). We did something similar for injecting service account tokens into the workspace.
    • I believe you'll have to create a volume and volumeMount for mounting the ssh-askpass.sh script, and then create a configmap on the cluster which mounts into the volume and contains the ssh-askpass.sh contents as its data.
    • Here's an example of creating a volume and volumeMount for a configmap. Your implementation will be much simpler however: we need to create a simple volume that mounts at a specific path /usr/local/bin/ssh-askpass.sh and add it to the workspace's pod additions (like we do for the serviceAccountToken volumes)
    • Here's an example of creating a configmap that has some data (again, this example is more complex than the current case but should give some ideas).

from devworkspace-operator.

Lastly, something that slipped my mind during the review of your original PR for supporting ssh passphrases: instead of adding the ssh-add environment variables directly into the project clone image, we could add them into the container's environment variables. An argument against this approach however, is that users who provide their own project clone container image might not want these environment variables set for them.

I don't think we need to do anything about this, but I wanted to mention this here incase the topic ever comes up.

from devworkspace-operator.

moving to the next release for 3.17 - https://issues.redhat.com/browse/CRW-6614?focusedId=25289708&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#commen[…]289708

from devworkspace-operator.

@dmytro-ndp to be clear: the issue with CheCode not being able to push to the repo using the UI might be a CheCode issue, though we can only confirm this once the DWO-side issue is resolved (i.e. when the git push over terminal with an ssh passphrase key works without prompting the user for the passphrase)

from devworkspace-operator.

I believe the issue with git pushing from terminal prompting the user for the passphrase is because we do not have the required ssh-add environment variables injected into the workspace containers (only the project clone container has them).

We could either add the DISPLAY & SSH_ASKPASS environment variables to all devworkspace containers, or try to add it only to the tooling container, similar to how we infer the tooling container component when determining the image for the persistent-home-init-container.

@vinokurig @dkwon17 any thoughts?

from devworkspace-operator.

@AObuchow I believe that the problem is in the DWO side indeed. From the recording we see that the git push command called from terminal invokes the default ssh-askpass tool. Looks like we need to propagate the ssh-askpass.sh script to the workspace container as well.

My thoughts exactly :) I was just about to finish writing my comment when you posted your comment.

Edit: I hadn't realized we weren't propagating ssh-askpass.sh as well. It seems we'll have to inject it into the workspace container(s) as well as the required environment variables.

from devworkspace-operator.