Che: Allow Che 7 Git + SSH Flow

[l0rd]

The problem

As mentioned in #12850 git+ssh is currently not working (cloning a project). A user is able to generate an SSH key pair with the ssh plugin (even if currently this plugin doesn't seems to be included in che-theia) but:

• cloning may happen at IDE startup (a user won't be able to generate the keys)
• git in che-theia doesn't support SSH
• ssh keys are only available in che-theia container

The proposed flow

Here is a list of steps/task of a git+ssh flow that I have splitted in 3 priority levels:

🦄critical for the GA: allow SSH key persistence and usage
🐴nice to have for the GA: automate for a better UX and get rid of the SSH plugin
🐮postponed after the GA: leverage GitHub token when available to automate even more

First time user login

• [x] 🐴Generate SSH keys when the user login for the first time and store them in user preferences #14411
• [ ] 🐮If a GitHub token is available upload the SSH key to GitHub

At workspace creation:

• [x] 🦄mount the SSH keys as secrets in all workspace containers #13520
• [x] 🐴setup (or mount?) git config (name and email) #13874

At workspace cloning with git+ssh:

• [ ] 🐴Check if the user can authenticate
• [ ] 🐴If the user cannot be auth but it's a GitHub URL
  
  
  
  • [ ] 🐮If we have his GitHub token: automatically upload the SSH key
  
  
  • [ ] 🐴If we don't have his GH token prompt him to upload the key manually
  
  
• [ ] 🐴If the user cannot be authenticated and it's not GitHub prompt the user to do the following steps after the workspace is started 1) generate the key using the addon if that hasn't been done yet 2) add its SSH public key to the git server 3) clone the project or restart the workspace

Misc

• [x] 🦄Add git+ssh support in che-theia container #12850
• [x] 🦄Enable the SSH plugin
• [ ] 🐴Make sure that current Che 7 stacks have git+ssh support
• [ ] 🐴Add git+ssh scenario in e2e happy path tests

[l0rd]

@vparfonov @evidolob can you please review and split up the critical tasks (🦄) amongst your teams?
cc @slemeur @sunix @benoitf please review as well

[benoitf]

@l0rd I thought git+ssh was working on che-theia. What are the steps used to have it "not working" ?

[l0rd]

@l0rd I thought git+ssh was working on che-theia. What are the steps used to have it "not working" ?

@benoitf that's described here #12850

[benoitf]

@l0rd OK somehow the previous fix has been lost, will fix it.

[vparfonov]

FYI SSH plugin for shh key management use wsagent at the moment

[l0rd]

@vparfonov as a first step a user need to be able to:

• add an SSH key-pair to the user preferences (it can be through the SSH plugin or another plugin)
• use his SSH key-pair with the git client (mount it as a secret in che-theia and other containers)

Adding a command to generate the key-pair is something that can be done as second step: initially we can request users to generate the key pair manually.

[l0rd]

We have reviewed this with @vparfonov and we are not going to address the problem of the git+ssh within a container where the user doesn't exist (arbitrary user). @vparfonov is going to create an issue instead that is going to be added to the known issue section in the documentation.

[l0rd]

We have discussed that the current behavior of the SSH plugin should be changed.

1. There should be 2 generate commands: SSH: generate key pair... and SSH: generate key pair for particular host...
2. SSH: generate key pair for particular host... works as the currently implemented in https://github.com/eclipse/che-theia/pull/352/files
3. SSH: generate key pair... instead would add a key for the generic host

Host *
  IdentityFile <path>

1. SSH: generate key pair... would send a request the the SSH manager with parameters { "service" : "vcs", "name": "default-<timestamp>"}
2. When a user call SSH: generate key pair... a second time a new key will be generated and added, the previous keys won't be deleted.

[l0rd]

@vparfonov I am removing this issue from 7.0.0 since all the GA stuff has been addressed. Setting it 7.1.0

[gorkem]

@azatsarynnyy @vparfonov Preserving the known_hosts between workspaces/sessions and git config for user and mail #13874 are the 2 priority issues on this flow as far as I can see.

[azatsarynnyy]

@gorkem we're finalizing preserving git config.
known_hosts issue is planned for the next sprint.

[nickboldt]

So I guess this has slipped to 7.2.0? fixing milestone accordingly.

[l0rd]

@nickboldt part of it has been implemented in 7.1.0, another part will be implemented in 7.2.0 but I am not sure that everything will be completed at the end of this sprint. In particular the part mentioned in First time user login is not planned yet.

[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.

[ericwill]

How much is there left to do here? It seems the vast majority of use cases are solved, maybe it's time we close this one and use a more recent ticket?

[l0rd]

@ericwill what is currently missing is checking if the user has privileges to clone at the startup of the workspace. Current UX is not ideal if you click on a factory link of a devfile with a git+ssh URL and you do not have the SSH key uploaded on the git server yet.

[l0rd]

@ericwill what is currently missing is checking if the user has privileges to clone at the startup of the workspace. Current UX is not ideal if you click on a factory link of a devfile with a git+ssh URL and you do not have the SSH key uploaded on the git server yet.

@ericwill in this sprint and next one platform team is working on something that is related to that