feat: add support for ssh pubkeys storing / validating / retrieving

[SalimKayal]

Summary

Adds SSH public keys to data-services: a per-user key store and API, plus the internal endpoints the SSH gateway uses to turn a presented key into a Renku user and check that the user may open a session. This is the integration PR for the SSH keys stack, landing the union of the three stacked PRs (store foundation, user API, proxy endpoints).

Motivation and context

Renku sessions are reachable over SSH through a new gateway. At the first hop the gateway has no user identity yet: it derives one from the public key the user offers. That needs two things data-services did not have: somewhere to register user public keys, and a machine callable endpoint that resolves a key to a user and authorizes the session. Internal services today either run in-process or call data-services with user scoped tokens, and neither fits a caller that has no user context yet.

The deployment already anticipates this: the umbrella Helm chart mounts the Renku internal authn key into the ssh-proxy pod, the same key data-services verifies for internal JWTs. So the proxy authenticates with the existing internal token mechanism, restricted by a new service scope, instead of introducing another credential.

Behavior

• Users can add, list, and remove their own SSH public keys through /user/ssh_keys. Each key is canonicalized (comment stripped) and fingerprinted exactly as ssh-keygen -l reports.
• One fingerprint maps to exactly one user, and every key route is owner scoped: an admin cannot read or remove another user's key.
• The gateway resolves a presented key with POST /internal/ssh_keys/identity, which returns the owning user id (200) or 404. Malformed and unknown keys are both a plain 404, so the proxy has one failure branch.
• The gateway checks session access with GET /internal/sessions/{session_id}/authorize, which returns 204 for the session owner and 404 otherwise. Not-owner and not-found are indistinguishable, so session existence is never disclosed.
• Both internal endpoints require an ssh_proxy scoped Renku internal token. User tokens and ordinary session internal tokens are rejected with 401.

Changes

• Users: users.ssh_keys table and Alembic migration; SSHKey and UnsavedSSHKey models; OpenSSH compatible fingerprint plus key validation; SSHKeyRepository; /user/ssh_keys CRUD blueprint and spec.
• Authn: RenkuSelfAuthenticator gains an optional required_scope. The existing internal JWT is reused, with no new credential or secret.
• SSH proxy: a new ssh_proxy component with its own spec and blueprint for the two internal endpoints, plus the SSH_PROXY_SCOPE constant.
• Wiring: DependencyManager and app.py register the new repository, authenticator, and blueprints; the merged OpenAPI spec includes the new component.
• Tests: key validation and fingerprint vector tests, repository CRUD and cross user scoping, /user/ssh_keys end to end, service scope accept and reject, and internal endpoint tests (identity 200/404, authorize 401/404/422, owner versus other user).

---

/deploy

[coveralls]

Coverage Report for CI Build 38417907356

Coverage at 85.264% (no base build to compare)

Details

• Coverage remained the same as the base build.
• Patch coverage: 22 uncovered changes across 5 files (359 of 381 lines covered, 94.23%).
• No coverage regressions found.

Uncovered Changes

File	Changed	Covered	%
components/renku_data_services/app_config/config.py	31	18	58.06%
components/renku_data_services/notebooks/core_sessions.py	62	57	91.94%
components/renku_data_services/notebooks/config/dynamic.py	15	13	86.67%
components/renku_data_services/ssh_proxy/blueprints.py	27	26	96.3%
components/renku_data_services/users/db.py	40	39	97.5%
Total (23 files)	381	359	94.23%

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	34841
Covered Lines:	29707
Line Coverage:	85.26%
Coverage Strength:	1.48 hits per line

---

💛 - Coveralls

[leafty]

Question:

an admin cannot read [...] another user's key.

Why? A public keys is a public key is public.

Restrictions on admin accessing public keys may make admin work more difficult, e.g. checking suspicious activity linked to a SSH key.

[SalimKayal]

Why? A public keys is a public key is public.

Not really for security reasons but mainly because

1. it simplifies the code
2. I see no reason why an admin would actually need to see one.

If it's useful to add this, I can do it.

[RenkuBot]

You can access the deployment of this PR at https://renku-ci-ds-1441.dev.renku.ch

[RenkuBot]

Tearing down the temporary RenkuLab deployment for this PR.