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 [email protected]

Or maybe even:

ssh [email protected]

(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 ?

[gtsiolis]

Cross-posting a relevant discussion (internal) with some specs in case you haven't seen this @iQQBot!

[david-bakin]

(I just thought I'd memorialize here some information jeanp413 looked up for me:)

VSCode Desktop no longer, with the ssh bridge, remembers previous open editors when you open a workspace and connect. (It used to remember them properly with the desktop connector. And it should because that's part of the Gitpod experience: just pick up where you left off.

jeanp413 (on Discord):

I took a look and this is a side effect as we are using a new random owner token every time a workspace is started e.g. <worspaceid>#<randomToken>@<workspaceid>.ssh.ws-us46.gitpod.io this is the ssh destination that we are connecting currently
This issue won't happen once you can upload your ssh keys #9932 in the near future and the random token won't be needed anymore

[axonasif]

Q: Will the random token method be still there?

Asking because it's helpful in some use cases, where you just want to grab the command and run somewhere like in an android terminal emulator(termux) without having to worry about uploading keys.

[loujaybee]

Updating that this the first iteration of this is now announced: https://www.gitpod.io/blog/ssh-key-upload 🙏

Will measure/gather feedback then look to close this issue.

[loujaybee]

Would be amazing if after adding a key you could simply do: ssh [email protected] - @florisvdg

Wanted to note that there's a separate issue (see below) here for simplifying the host name, also. Some technical constraints why we can't do it right away, but hopefully we can simplify the connection further so it's possibly even memorisable, or at least easier to work with when copying into SSH connection forms, etc.

• Simplify SSH host - for memorising, constructing from URL, and pasting into SSH clients #11355

[loujaybee]

Marking issue as complete, see:

• https://www.gitpod.io/blog/ssh-key-upload
• https://www.gitpod.io/blog/vscode-desktop-ssh-updates

For more details.