Only add SSH Agent PostStart event if SSH key with passphrase is used

[AObuchow]

Currently, we are adding the init-ssh-agent-command-... postStart event unconditionally to all workspaces.
There are cases where this automatically-injected postStart event can actually cause the workspace to fail. For example, if a devworkspace contains a container component that uses a distro-less image where sh is missing, as described here.

We should instead only inject the init-ssh-agent-command-... postStart event if the SSH secret that will be mounted to the workspace pod actually requires a passphrase.

Short term solution

In the short term, we could check if there's an SSH secret with a predefined name git-ssh-key (that the Che Dashboard uses) in the workspace's namespace, and check if it has a passphrase. However, this solution creates a coupling between DevWorkspace Operator and the Eclipse Che Dashboard, as DWO does not actually enforce you to name your SSH secret git-ssh-key. Instead, it's only given as an example SSH secret name in the docs.

Long term solution

In the long term, echo'ing @l0rd's thoughts, we should revise how the automatic SSH passphrase injection is handled:

In general I think that #1307 was a bad idea because there is a high risk to break existing workspaces (we just found 2 container images where the command failed, there may be more). And no matter the value of the new feature implemented, avoiding breaking existing workspaces should be the priority. Also we should avoid, at the DWO level, to modify a DW applied by a user. The dashboard does an automatic generation of DW, so why not adding the post start event there?

Some ideas:

• Move all SSH agent functionality (creation of the SSH agent configmap script & the injection of the postStart event) to the Che Dashboard
• Keep the SSH agent functionality in DWO, but have it enabled only when a devworkspace attribute is provided, e.g. controller.devfile.io/initialize-ssh-agent: true. The Che Dashboard could then add this attribute to devworkspace's when the user provides an SSH key that has a passphrase.

[AObuchow]

@l0rd BTW I was unable to pull the specific version of your distro-less image that does not contain sh unfortunately:

$ docker pull ghcr.io/l0rd/outyet@sha256:b83e158687d6cb3d7ae46382be1e4fbb8eb3572f3423a9c3c9beae6cd55cc0e8
ghcr.io/l0rd/outyet@sha256:b83e158687d6cb3d7ae46382be1e4fbb8eb3572f3423a9c3c9beae6cd55cc0e8: Pulling from l0rd/outyet
unsupported media type text/spdx+json

$ podman pull ghcr.io/l0rd/outyet@sha256:b83e158687d6cb3d7ae46382be1e4fbb8eb3572f3423a9c3c9beae6cd55cc0e8
Trying to pull ghcr.io/l0rd/outyet@sha256:b83e158687d6cb3d7ae46382be1e4fbb8eb3572f3423a9c3c9beae6cd55cc0e8...
Getting image source signatures
Copying blob e2ecab31c0f4 done   | 
Error: writing blob: adding layer with blob "sha256:e2ecab31c0f45ca127dc34b63091f1e1dcad7cceedd6a3f140314bf3f55a4879"/""/"sha256:e2ecab31c0f45ca127dc34b63091f1e1dcad7cceedd6a3f140314bf3f55a4879": unpacking failed (error: exit status 1; output: archive/tar: invalid tar header)
exhausting input failed (error: archive/tar: invalid tar header)

[l0rd]

@AObuchow, you are right. I got the same error. You can try with ghcr.io/l0rd/outyet@sha256:3ab91b5801ab2e2a6147cab5d4a959838d9318921298e84cf7b6d19a3359e496 if you like. But there is nothing special. It's an image for a go application built with ko, which is pretty common.