Enable MAS local password login for terminal client (iamb) #13

New issue

Open

opened 2026-08-08 13:05:24 +00:00 by paul · 2 comments

paul commented

2026-08-08 13:05:24 +00:00

Owner

Summary

Enable local password login in MAS so a terminal Matrix client (iamb) can authenticate. Currently MAS is SSO-only (passwords.enabled: false, delegating to Authentik via upstream_oauth2), and legacy /_matrix/client/v3/login returns M_UNRECOGNIZED. iamb 0.0.11 has no MSC2965/OIDC support, so it cannot log in at all.

Motivation

Want a terminal Matrix client on the desktop (same account as Element X on mobile, @paul:gierz.eu). gomuks-terminal is still experimental (needs separate backend + web-only Matrix login), so iamb is the preferred TUI — but it needs a password/compat login endpoint.

Proposed change

roles/mas/templates/config.yaml.j2 (~line 56):
```
passwords:
  enabled: true
```
(compat listener resource is already enabled, so no listener change needed.)
Redeploy: ansible-playbook playbooks/mas.yml (host gierz-services).
Set a local password for the account (OIDC accounts have none):
```
podman exec -it mas mas-cli manage set-password paul
```

Tradeoff / decision needed

This adds a parallel local-password path alongside Authentik for the same account — two credential routes into @paul. Security posture changes: the SSO-only guarantee is relaxed. Consider:

Leaving password_registration_enabled: false / password_recovery_enabled: false as-is (already set) so only manually-set passwords work.
Whether to scope this to admin/self only.
Alternative: keep MAS pristine and instead run gomuks (backend + web one-time OIDC login) — no auth change, but heavier client setup.

Acceptance

Decision on local-password vs keep-SSO-only
If approved: config change committed, mas.yml deployed
@paul password set in MAS
iamb logs in via [p]assword against https://gierz.eu

## Summary Enable local password login in MAS so a terminal Matrix client (iamb) can authenticate. Currently MAS is SSO-only (`passwords.enabled: false`, delegating to Authentik via `upstream_oauth2`), and legacy `/_matrix/client/v3/login` returns `M_UNRECOGNIZED`. iamb 0.0.11 has no MSC2965/OIDC support, so it cannot log in at all. ## Motivation Want a terminal Matrix client on the desktop (same account as Element X on mobile, `@paul:gierz.eu`). gomuks-terminal is still experimental (needs separate backend + web-only Matrix login), so iamb is the preferred TUI — but it needs a password/compat login endpoint. ## Proposed change - `roles/mas/templates/config.yaml.j2` (~line 56): ```yaml passwords: enabled: true ``` (`compat` listener resource is already enabled, so no listener change needed.) - Redeploy: `ansible-playbook playbooks/mas.yml` (host `gierz-services`). - Set a local password for the account (OIDC accounts have none): ```sh podman exec -it mas mas-cli manage set-password paul ``` ## Tradeoff / decision needed This adds a **parallel local-password path alongside Authentik** for the same account — two credential routes into `@paul`. Security posture changes: the SSO-only guarantee is relaxed. Consider: - Leaving `password_registration_enabled: false` / `password_recovery_enabled: false` as-is (already set) so only manually-set passwords work. - Whether to scope this to admin/self only. - Alternative: keep MAS pristine and instead run gomuks (backend + web one-time OIDC login) — no auth change, but heavier client setup. ## Acceptance - [ ] Decision on local-password vs keep-SSO-only - [ ] If approved: config change committed, `mas.yml` deployed - [ ] `@paul` password set in MAS - [ ] iamb logs in via `[p]assword` against `https://gierz.eu`

paul commented

2026-08-08 13:06:22 +00:00

Author

Owner

@erwin, can you provide a summary of the current state please?

erwin commented

2026-08-08 13:12:03 +00:00

Collaborator

Current state (verified against `main` @ `f66df36`)

MAS config (roles/mas/templates/config.yaml.j2):

passwords.enabled: false (line 56–57) — SSO-only, as designed. Header comment on line 9 documents the intent: "passwords: off (SSO only)".
compat listener resource is already in the human listener's resource list (line 19), so the legacy /_matrix/client/v3/login endpoint is served — it just rejects password login while passwords.enabled is false. No listener change needed, matching the issue's proposal.
account section (lines 71–75): password_registration_enabled: false, password_recovery_enabled: false, email_change_allowed: false — all already locked down. If we flip passwords.enabled: true, only manually set passwords (via mas-cli manage set-password) would work; no self-service path opens up.
upstream_oauth2 → Authentik remains the primary route (line 79), untouched by this change.

No existing branch touches this — nothing matching mas/iamb/password in the worktree list.

So the delta is exactly one line (enabled: false → true) + redeploy (playbooks/mas.yml, host gierz-services) + one manual mas-cli manage set-password paul inside the mas container.

Decision still open (acceptance box 1): relax SSO-only for @paul vs. keep MAS pristine and go the gomuks route. My read: the blast radius is small — registration/recovery stay off, so the only new credential is one you set by hand, and it can be reverted by flipping the flag back and redeploying. The main cost is conceptual: "Authentik is the only door" stops being true for this one account.

Say the word and I'll cut a branch erwin/mas-local-password with the one-line change; the deploy command stays yours to run.

## Current state (verified against `main` @ f66df36) **MAS config (`roles/mas/templates/config.yaml.j2`):** - `passwords.enabled: false` (line 56–57) — SSO-only, as designed. Header comment on line 9 documents the intent: "passwords: off (SSO only)". - `compat` listener resource is already in the `human` listener's resource list (line 19), so the legacy `/_matrix/client/v3/login` endpoint is served — it just rejects password login while `passwords.enabled` is false. **No listener change needed**, matching the issue's proposal. - `account` section (lines 71–75): `password_registration_enabled: false`, `password_recovery_enabled: false`, `email_change_allowed: false` — all already locked down. If we flip `passwords.enabled: true`, only *manually set* passwords (via `mas-cli manage set-password`) would work; no self-service path opens up. - `upstream_oauth2` → Authentik remains the primary route (line 79), untouched by this change. **No existing branch touches this** — nothing matching `mas`/`iamb`/`password` in the worktree list. **So the delta is exactly one line** (`enabled: false` → `true`) + redeploy (`playbooks/mas.yml`, host `gierz-services`) + one manual `mas-cli manage set-password paul` inside the `mas` container. **Decision still open (acceptance box 1):** relax SSO-only for `@paul` vs. keep MAS pristine and go the gomuks route. My read: the blast radius is small — registration/recovery stay off, so the only new credential is one you set by hand, and it can be reverted by flipping the flag back and redeploying. The main cost is conceptual: "Authentik is the only door" stops being true for this one account. Say the word and I'll cut a branch `erwin/mas-local-password` with the one-line change; the deploy command stays yours to run.