Epic: Upload users SSH keys to Gitpod

[loujaybee]

Context

Local companion dynamically creates SSH keys for users, to grant SSH access, and the copy/paste SSH method for Gitpod uses an access code from within the workspace, and you can even manually inject your SSH public key using dotfiles. Whilst both of these approaches work, it would be better to allow users to upload their own SSH public keys to Gitpod to access their workspace using a more conventional SSH approach. We may also want to consider re-using existing public keys from GitHub, or other providers, for instance.

Value

1. Improved security (as not using a token)
2. A simpler UX for SSH'ing into workspaces
3. A more familiar SSH pattern (matches with user expectations)

In Scope

• Uploading custom keys

Out of scope

• Pulling SSH keys from 3rd party providers

Related Issues

• [SSH Gateway] remove private key requirement when ownerToken is provide #10704
• [ws-proxy, ws-manager] support user upload ssh public key #10617
• Support ssh public keys configuration #10573
• https://github.com/gitpod-io/website/issues/2371
• https://github.com/gitpod-io/website/issues/2375
• db-sync fails to sync SSHPublicKeys #11265

Public FAQ

Will we allow users to add SSH keys manually?

Yes.

Will we keep the current owner token SSH solution in place?

Yes, as there is value in the quick copy/paste, however SSH key upload should be recommended.

Will importing SSH keys from GitHub be the primary way add SSH keys?

Unlikely. Uploading custom keys would be the simplest implementation, which we could then extend with ways to fetch existing keys as a future update or refinement. We will start by setting up the Gitpod infrastructure for using SSH keys, and then look at ways to import/re-use existing keys from other providers.

Can we fetch SSH keys from all other providers (GitHub, BitBucket, GitLab)?

- GitHub has an API - GitLab has an API - BitBucket needs to be investigated

Can you use an SSH Key from one provider to connect to workspaces for repositories in other providers?

Needs investigation.

Internal FAQ

What happens if SSH keys get removed from a provider, can we detect that?

Needs investigation

[loujaybee]

Closing as duplicate of: #6794

[loujaybee]

Re-opening as #6794 looks to be about gitpod -> external service.

Whereas this issue was intended to be about user -> gitpod connection.

[akosyakov]

@iQQBot Do you think a user can somehow make use of dot files to work around it for now?

[florisvdg]

Couldn't agree more. This access code mechanism is a nice hack, but not so great. I expected a public key text box (e.g. https://github.com/settings/ssh/new) in some Gitpod settings pane like every other platform out there that offers SSH functionality.

Would be amazing if after adding a key you could simply do:

ssh gitpod@my-workspace.gitpod.io

Or maybe even:

ssh my-workspace@gitpod.io

(Icing on the cake would be supporting agent forwarding too: #6993)

[iQQBot]

As @csweichel suggestion
We can do like this

1. add UI and API to accept the user's public key. Maybe we can pull this from GitHub (what about the other hoster)
2. push the through server -> ws-manager -> pod -> ws-proxy (annotation in pod)
3. support that key in the SSH gateway functionality of ws-proxy

Or

1. introduce a supervisor API which can get ~/.ssh/authorized_keys
2. when a workspace start, connecting to server download ssh public key store in ~/.ssh/authorized_keys
3. ws-proxy call supervisor API, valid the key

Or (this case can support dynamic valid, it will auth each time, i.e. you can upload ssh key, and it work with an opened workspace, above 2 option only work on new workspace)

1. introduce a supervisor API which can get community with server
2. ws-proxy call supervisor API, supervisor call server api, valid the key

Actually, I like solution 1, it looks more simple WDYT @csweichel ?