access tokens don't provide authentication

[ByteSizedMarius]

Describe the bug

I've noticed some anomalies in the token system for soft-serve, namely:

1. It seems that KeyboardInteractiveHandler ignores the token challenge, so tokens are not checked. A user given a token to access soft serve gets the same access as someone with no token at all (for AllowKeyless=true). With AllowKeyless=false, a valid token is rejected identically to an invalid one.
2. Token-authenticated sessions have no user identity, so collaborator-based access control is bypassed. Instead, I expected KeyboardInteractiveHandler to validate the token via UserByAccessToken and resolve the user identity in AuthenticationMiddleware.

If unintentional, token-based access control is "silently" broken. If this is intentional, Id appreciate clarification on the intended use case for access tokens.

To Reproduce
Steps to reproduce the behavior:

1. Create a user and token: ssh -p 23231 localhost token create mytoken
2. Set AllowKeyless=false: ssh -p 23231 localhost settings allow-keyless false
3. Connect with the valid token via keyboard-interactive -> connection is rejected
4. Set AllowKeyless=true: ssh -p 23231 localhost settings allow-keyless true
5. Connect with any random string via keyboard-interactive -> connection is accepted

In both configurations, the token value has no effect on the outcome.

Additionally, since token-authenticated sessions have no user identity, AuthenticationMiddleware does not resolve the user, so collaborator-based repo filtering in repo list does not apply. This means that a private repo the user was added to as a collaborator isn't shown.

Expected behavior
KeyboardInteractiveHandler should validate the token via UserByAccessToken and accept/reject based on whether the token is valid. Valid tokens should be accepted regardless of AllowKeyless. The resolved user identity should be set in the session context so collaborator-based access control works for token-authenticated sessions.

[aymanbagabas]

Hi @ByteSizedMarius. Thank you for reporting this one.

How are you using access tokens? FWIW, access tokens are used in HTTP Soft Serve that replace the basic auth method. The allow-keyless setting affects SSH key authentications and access.

[ByteSizedMarius]

I needed programmatic access to the admin api and was unable to use ssh keys for my specific use case. I saw that most of the infra for token auth was already there, just not wired up to ssh auth. It seems I misunderstood your intended scope of tokens.

Currently, KeyboardInteractiveHandler is just a gate for allow-keyless, but it's trivial to use the gossh.KeyboardInteractiveChallenge to ask for a token and fall back to allow-keyless otherwise. The only other change required is making the ssh middleware respect a users permissions based on a token (in addition to the key). I feel like this would be quite useful, but I understand if you think its unnecessary. Alternatively, http access to admin stuff would allow for the same use cases.

In any case, this can be closed, I guess. Thanks for the clarification