Che: SSH keys are available to all containers only after workspace reboot

[ScrewTSW]

Describe the bug

After using the >SSH generate key-pair command, the keypair is generated in the theia-ide container only, not accessible for the other running containers.

By default the terminal can be only opened for the deployment container.

It can be circumvented by showing the tool containers or running a new terminal from My Workspace->Plugins->theia-ide

However, after the reboot the key is available in /etc/ssh and the checkout works from all containers.

I would suggest instead of storing the key into /home/theia/.ssh to store it straight into /etc/ssh and restarting the sshd daemon @vparfonov

Che version

• [ ] latest
• [ ] nightly
• [x] other: please specify (hosted che @ che.prod-preview.OSIO) 7.0.0-rc-4.0
  

Expected behavior

The git clone should be possible from any container right after the key has been generated and added into your git service of choice

Runtime

• [ ] kubernetes (include output of kubectl version)
• [x] Openshift (include output of oc version)
• [ ] minikube (include output of minikube version and kubectl version)
• [ ] minishift (include output of minishift version and oc version)
• [ ] docker-desktop + K8S (include output of docker version and kubectl version)
• [ ] other: (please specify)

OpenShift Master: v3.11.82
Kubernetes Master: v1.11.0+d4cacc0
OpenShift Web Console: v3.11.82

Installation method

• [ ] chectl
• [ ] che-operator
• [ ] minishift-addon
• [x] I don't know

Environment

• [ ] my computer
  
  
  
  • [ ] Windows
  
  
  • [ ] Linux
  
  
  • [ ] macOS
  
  
• [x] Cloud
  
  
  
  • [ ] Amazon
  
  
  • [ ] Azure
  
  
  • [ ] GCE
  
  
  • [ ] other (please specify)
  
  
• [ ] other: please specify

[ibuziuk]

@vparfonov @vinokurig guys, wdyt? my understanding that this issue is not che.openshift.io specific

[vinokurig]

It is not possible to store keys in the /etc/ssh after generating a key, there is no wright access.

[vparfonov]

Looks like we don't have solution at the moment, so i will remove 7.0.0 milestone

[ibuziuk]

@vparfonov this issue looks quite important and I guess both minishift and minikube are also affected, right?
could we consider workarounds like:

• store keys initially in the writable dir e.g. projects
• restart workspace after key pair generation
  cc: @l0rd @slemeur

[ScrewTSW]

@vparfonov this issue looks quite important and I guess both minishift and minikube are also affected, right?
could we consider workarounds like:

* store keys initially in the writable dir e.g. `projects`

* restart workspace after key pair generation
  cc: @l0rd @slemeur

alternate would be to get all running containers other than theia-ide and copy it into the home folders of users running there

cp -R /projects/ssh /home/$(whoami)/.ssh
rm -rf /projects/ssh

This would prevent us from having to restart the workspace.

[vparfonov]

@ibuziuk @ScrewTSW

• Put ssh keys in /projects/.ssh folder can be solution but it will looks strange for our user. Also in this case we don't need mount ssh keys as k8s secrets.
• Restart workspace after generate keys is not acceptable i think.

But actual problem even not there is no wright access. Problem is that SSH key generate in one container and put it in /home/theia/.ssh but try to use in other container. If we will store keys in /projects folder it will solve the problem because this folder mount to each container, but again it will looks strange to see SSH key in project tree.

[ibuziuk]

ff we will store keys in /projects folder it will solve the problem because this folder mount to each container, but again it will looks strange to see SSH key in project tree.

I agree, but it is better than just the fact that SSH will not work at all just after generation without workspace restart

Also in this case we don't need mount ssh keys as k8s secrets.

The idea is to store SSH in the projects only initially, after restart it should be in /etc/ssh just like now

Restart workspace after generate keys is not acceptable i think.

well, we need to either workaround it somehow or notify user that SSH are generated but can be used only after workspace restart

[l0rd]

The solution here is avoiding to ask users to generate an SSH key and do that automatically as soon as a user login to Che the first time. @ibuziuk @ScrewTSW please have a look at https://github.com/eclipse/che/issues/13494

As a workaround we can provide a message (don't we do that already?) but I expect @vparfonov team to implement this rapidly after Che 7 is released.

[vinokurig]

@l0rd

As a workaround we can provide a message (don't we do that already?)

We don't. What about a notification: WARNING: the key is available only in 'theia-ide' container! It will be available for all containers after workspace restart.?

[l0rd]

@vinokurig I would make it even simpler: `Please restart your workspace to access the generated SSH keys"

[vinokurig]

@lord

@vinokurig I would make it even simpler: `Please restart your workspace to access the generated SSH keys"

This message looks like the SSH keys don't work at all, but they are available in theia-ide container and the Git plugin can access the keys as well

[l0rd]

@vinokurig I understand that but I don't expect a user to know what the theia-ide container is and how to open a shell on it. He will lose more time to figure that out then restarting the workspace.

You are right for the Git plugin though so maybe

Che Git plugin can leverage the generated keys now. To make them available in every workspace containers please restart your workspace.

But not sure if that's better. Simpler is usually better. And anyway that's a temporary message because we need to fix #13494!

[sunix]

I thought we were mounting the keys somehow in /etc/ssh but maybe i missed understood something ...
what was that about ? https://github.com/eclipse/che/issues/13520

[vparfonov]

I thought we were mounting the keys somehow in /etc/ssh but maybe i missed understood something ...
what was that about ? #13520

Yes it's true! We mount in/etc/ssh

[sunix]

I thought we were mounting the keys somehow in /etc/ssh but maybe i missed understood something ...
what was that about ? #13520

Yes it's true! We mount in/etc/ssh

if we mount, we can decide to have write access no ?

[sunix]

I thought we were mounting the keys somehow in /etc/ssh but maybe i missed understood something ...
what was that about ? #13520

Yes it's true! We mount in/etc/ssh

if we mount, we can decide to have write access no ?

@vparfonov @vinokurig @l0rd why don't we write to it : we mount it we can have write access.

[vinokurig]

@sunix

@vparfonov @vinokurig @l0rd why don't we write to it : we mount it we can have write access.

wright access will not solve the problem, It doesn't matter where the keys are located after generation, in /etc/ssh or in ~/.ssh. The problem is that the key file is generated only for theia-ide container.

[sunix]

If you mount a volume ... it could be mounted in all the containers including theia-ide.

[gorkem]

@vinokurig @vparfonov Are you mounting ssh keys as a secret to the pod?

[vparfonov]

@vinokurig @vparfonov Are you mounting ssh keys as a secret to the pod?

Yes

[ScrewTSW]

bump.

[ScrewTSW]

Any plans for fixing this issue?

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.