# ADR-007: Terminal Access Auth Model (Console vs Direct SSH)

## Status
Accepted

## Date
2026-03-01

## Author
GPUaaS Core Team

## Context
GPUaaS supports two operator/user access surfaces to allocated nodes:
- browser console terminal (platform-managed),
- direct SSH from user environment (network-dependent).

Past iterations mixed SSH transport assumptions with console terminal behavior, which
created ambiguity around credentials, onboarding keys, and user-facing login prompts.

We need a stable security model that is simple for MVP and extensible post-MVP.

## Decision
- Browser console terminal is the primary managed access path:
  - Auth at open: OIDC session + short-lived single-use terminal token.
  - Runtime transport: terminal gateway -> internal relay -> node-agent stream.
  - Node-side execution identity: allocation user (`username_on_node`/uid/gid), not root.
  - No username/password prompt UX in browser terminal.

- Direct SSH is optional and user-managed:
  - Platform stores and manages only user public keys.
  - Platform does not store or return user private keys.
  - UI may display connection metadata/commands (`user@host -p port`) but does not
    implement a managed SSH session flow.

- MaaS/manual onboarding keys are infrastructure-plane credentials, not tenant access credentials:
  - node bootstrap/enrollment material is for node-agent trust establishment only.
  - onboarding credentials are never surfaced as terminal login prompts to end users.

- Password-based node login is out of MVP scope:
  - no default password auth path for tenant runtime access,
  - any future break-glass path must be admin-only, time-limited, audited, and separately specified.

## Consequences
- Clear separation of concerns:
  - terminal auth model is independent from SSH key transport model.
  - no coupling between node onboarding and tenant runtime auth UX.

- Security posture improves:
  - no private-key persistence/download flow in control plane.
  - terminal sessions remain policy-bound and auditable.

- UX implications:
  - terminal opens directly to shell when authorized (no interactive login prompt).
  - direct SSH guidance remains informational only.

## Alternatives Considered
- Unified SSH-only model for both browser and direct access:
  - rejected due to credential-management risk and poor fit for browser managed sessions.

- Password login in browser terminal:
  - rejected for MVP due to expanded secret lifecycle and higher abuse risk.

- Reusing MaaS/bootstrap credentials for tenant runtime access:
  - rejected; violates trust-boundary separation between infrastructure and tenant access.