[ws-proxy, ws-manager] support user upload ssh public key

[iQQBot]

Description

[ws-proxy, ws-manager] support user upload ssh public key
This is part of Epic: Upload users SSH keys to Gitpod #9932
It only contains workspace components change

Related Issue(s)

Relate #9932

How to test

Be sure to check to see if previous authentication has NOT been breached

1. start a workspace in this preview environment, and get this workspace instanceID (e.g. 90147062-a363-44d1-9516-e7b9bc07ac54)
2. start a workspace using this branch (in order to get test gpctl) the following command will be execute at this workspace

# replace 90147062-a363-44d1-9516-e7b9bc07ac54 as your workspace Instance ID
# build gpctl
cd /workspace/gitpod/dev/gpctl && go build

# generate a ssh key pair
ssh-keygen

# update local ssh
./gpctl workspaces update-ssh-keys 90147062-a363-44d1-9516-e7b9bc07ac54 ~/.ssh/id_rsa.pub

# check annotation with kubectl
kubectl describe pods ws-90147062-a363-44d1-9516-e7b9bc07ac54 | grep "gitpod.io/sshPublicKeys" -C 3

# test ssh into this workspace, remember don't include ownerToken
ssh workspaceID@workspaceID.ssh.ws.pd-use-userpk2.preview.gitpod-dev.com

Release Notes

NONE

Documentation

/werft analytics=segment|TEZnsG4QbLSxLfHfNieLYGF4cDwyFWoe

[iQQBot]

/hold
need remove debug commit

[geropl]

Reviewed the core.proto changes, and those LGTM. 👍
(did NOT test)

/hold to ensure others can review as well

[akosyakov]

@iQQBot Should not How to test have tests for backward compatibility with current approach for all interfaces?

or you mean Be sure to check to see if previous authentication has NOT been breached implies it? and reviewer should know how to test it? Maybe we should have a Notion page for manual smoke testing of SSH client and share it on PRs and workspace team to verify after deployment?

[iQQBot]

@iQQBot Should not How to test have tests for backward compatibility with current approach for all interfaces?

I put a very large title in how to test section Be sure to check to see if previous authentication has NOT been breached , but I assume your are already known how to test previous authentication

[iQQBot]

@mustard-mh Thanks for your point, I changed the code

[iQQBot]

will add some CDWP test and remote debug commit, then merge it!

[mustard-mh]

/hold

Why only allow to add? How about set keys? (since we can delete keys in dashboard)

If we allow set keys after workspaces start, is that mean we need to kick conn out if their public keys have been deleted

Need more changes or explain that keys only work on the moment workspaces start and remove add function

Sorry, I'm working on dashboard and forget that what ws-manger-api provided is update, not add (add is in dashboard)

[iQQBot]

Why only allow to add? How about set keys? (since we can delete keys in dashboard)
If we allow set keys after workspaces start, is that mean we need to kick conn out if their public keys have been deleted
Need more changes or explain that keys only work on the moment workspaces start and remove add function

Any management of public keys will only work on newly established connections, adding or deleting public keys will real-time change the annotation of the workspace pod (need server calls UpdateSSHKey API), if the user deletes a key then the connection corresponding to this key will not be kicked out, just that no new connection can be auth with this key.

[mustard-mh]

Why only allow to add? How about set keys? (since we can delete keys in dashboard)
If we allow set keys after workspaces start, is that mean we need to kick conn out if their public keys have been deleted
Need more changes or explain that keys only work on the moment workspaces start and remove add function

Any management of public keys will only work on newly established connections, adding or deleting public keys will real-time change the annotation of the workspace pod (need server calls UpdateSSHKey API), if the user deletes a key then the connection corresponding to this key will not be kicked out, just that no new connection can be auth with this key.

I know what this PR doing, but want to know why we choose this way, and this behavior needs to be documented: Remove will not work for all started workspaces

[iQQBot]

I know what this PR doing, but want to know why we choose this way, and this behavior needs to be documented: Remove will not work for all started workspaces

This does not mean Remove will not work for all started workspaces

Remove will apply to all started workspaces, by updating annotation, i.e. Deleted ssh keys are not allowed to connect to these workspaces again.

However, connections that have been successfully established will not be affected, this behavior is consistent with openssh-server i.e. If you connect to a server via ssh, edit your ~/.ssh/authorized_keys in your server remove your public key, it will not affect this connection, but if you want to start a new ssh client, it will fail.

I will put this in the document. or put this as warning dialog when users try to delete their public key

[iQQBot]

/werft run

👍 started the job as gitpod-build-pd-use-userpk2.20
(with .werft/ from main)

[iQQBot]

Also test it using multi public keys, see screenshot key1, key2 is uploaded, key3 is new generate and not upload

[iQQBot]

fix a bug that let segment missing some trace

[iQQBot]

I would like to merge this

[iQQBot]

....Ah, again Conflicting files

[iQQBot]

/werft run

👍 started the job as gitpod-build-pd-use-userpk2.23
(with .werft/ from main)

[iQQBot]

/unhold