[ssh-gateway] Reject ssh connection when workspace not found

[iQQBot]

Description

[ssh-gateway] Reject ssh connection when workspace not found

For reviewer: In general, the SSH authentication process is as follows
NoClientAuthCallback -> PublicKeyCallback(if private key provider) -> PasswordCallback
there are 2 special error type

1. ssh.ErrNoAuth This Error only exists in the NoClientAuthCallback, which means that this callback is skipped and not counted as attempts
2. ssh.ErrDenied This Error means that retries are no longer allowed and the validation process is complete.
   All error created by NewSSHErrorWithReject is base on ssh.ErrDenied
   The new authentication process is simple than before

NoClientAuthCallback responsible for checking if workspace exists, if not, close the connection, if it does, determine if the username is in the form of workspaceId#ownerToken, if so, verify ownerToken, if the authentication fails, close the connection
PublicKeyCallback responsible for verifying the private key, the username check is removed here because the NoClientAuthCallback has already done it for us, so there is only one possibility that the username is a exists workspaceID.
PasswordCallback is similar with PublicKeyCallback but verify password (ownerToken).

Related Issue(s)

Fixes #11428

How to test

1. start a workspace in preview environment
2. connect ssh via copy/paste, it should be work
3. stop workspace
4. try use the previous command connect, it should terminated with error Connection closed instead of ask your provider password

Release Notes

NONE

Documentation

Werft options:

• /werft with-preview
• /werft analytics=segment|TEZnsG4QbLSxLfHfNieLYGF4cDwyFWoe

[werft-gitpod-dev-com]

started the job as gitpod-build-pd-reject-if-ws-nf.1 because the annotations in the pull request description changed
(with .werft/ from main)

[iQQBot]

if you use access token command to connect, it will still ask once your password (Limited by the standard library, we cannot dynamically decide whether to enable a certain authentication method)

This is because we want to be compatible with workspaceID#wrongOwnerToken@workspaceUrl when user using correct private key, if we don't compatible that way, we can remove this limited, I suggest removing this compatibility, we have never stated this way cc @akosyakov

[akosyakov]

This is because we want to be compatible with workspaceID#wrongOwnerToken@workspaceUrl when user using correct private key, if we don't compatible that way, we can remove this limited, I suggest removing this compatibility, we have never stated this way cc @akosyakov

What does it mean for user if workspace is running and private key is present? They will be able to connect successfully? What would be your expectation?

[iQQBot]

What does it mean for user if workspace is running and private key is present? They will be able to connect successfully? What would be your expectation?

I expectation we only support workspaceID@workspaceUrl for private key, and workspaceID#ownerToken@workspaceUrl for none private key

currently we support workspaceID#wrongOwnerToken@workspaceUrl for private key, which is not necessary

[werft-gitpod-dev-com]

started the job as gitpod-build-pd-reject-if-ws-nf.6 because the annotations in the pull request description changed
(with .werft/ from main)

[iQQBot]

This means that no more attempts are allowed and the connection is simply disconnected

[akosyakov]

I expectation we only support workspaceID@workspaceUrl for private key, and workspaceID#ownerToken@workspaceUrl for none private key
currently we support workspaceID#wrongOwnerToken@workspaceUrl for private key, which is not necessary

ok, let's try, @jeanp413 @felladrin could you check that it is aligned with expectations in JB GW plugin and VS Code Desktop extension 🙏

[jeanp413]

I deleted the workspaceID#wrongOwnerToken@workspaceUrl logic so I'd say remove it here too

[jeanp413]

@iQQBot it works but I see in the logs that it still tries to authenticate with gssapi-with-mic something with kerberos maybe we disable it in server too using GSSAPIAuthentication no in sshd_config

[iQQBot]

@iQQBot it works but I see in the logs that it still tries to authenticate with gssapi-with-mic something with kerberos maybe we disable it in server too using GSSAPIAuthentication no in sshd_config

This does not affect the fact that we do not have GSSAPIAuthentication enabled, but the client can still send it. Due to the limitations of the standard library, we cannot disconnect immediately, but will wait for a timeout of about 1-2s, during which time the client can still try to send authentication, but it will fail due to lack of response

[akosyakov]

@felladrin Assigned you to test how JB GW behaves with this change.

[felladrin]

Besides testing the SSH connection, as instructed in the How to Test section, I checked JetBrains IntelliJ (Stable and EAP) and JetBrains Gateway (Stable and EAP).

• Tested the full connection flow (start, connect, stop) (start, connect, disconnect, stop). All good.
• Tested trying to connect simultaneously as I stopped the workspaces, and Gateway will simply indicate the workspace is stopping/stopped and won't try to connect.
  
• Tested trying to connect to non-running workspaces, and I couldn't find any way to do it in JetBrains Gateway flow. It will always take the user to the workspace page where they need to re-start it.

[iQQBot]

@aledbf Could you have a look? It would be good if this PR can include gen55 🙏