TP30 — Credentials #20

Open
opened 2026-09-07 11:26:38 +02:00 by admin · 5 comments
Owner

Steuerungs-SSoT: Index/Status hier in Gitea; Prosa/Detail im Repo unter docs/teilprojekte.md (Abschnitt TP30).

  • Status: 🔜 (status:todo)
  • Abschluss: —
Steuerungs-SSoT: Index/Status hier in Gitea; **Prosa/Detail** im Repo unter `docs/teilprojekte.md` (Abschnitt `TP30`). - Status: 🔜 (status:todo) - Abschluss: —
admin added the status:todothema:infra labels 2026-09-07 11:26:38 +02:00
Author
Owner

Merkposten aus TP35-Abschluss (2026-09-12): authentifizierten mikromcp-Read on-network einmal verifizieren. Der Credential-Flip auf {env:} ist angewandt und die MCP-Server laden sauber; ausständig ist nur der On-Network-Smoketest (off-site: 10.40.99.1:80 connect-timeout, kein Auth-Fehler). Beim nächsten Standort-Besuch: check_router_health/Read gegen crs326-core — grün = Schicht-2-Restcheck erledigt.

Merkposten aus TP35-Abschluss (2026-09-12): **authentifizierten mikromcp-Read on-network einmal verifizieren**. Der Credential-Flip auf `{env:}` ist angewandt und die MCP-Server laden sauber; ausständig ist nur der On-Network-Smoketest (off-site: `10.40.99.1:80` connect-timeout, **kein** Auth-Fehler). Beim nächsten Standort-Besuch: `check_router_health`/Read gegen `crs326-core` — grün = Schicht-2-Restcheck erledigt.
Author
Owner

Ergänzung: durch Secret-Leak verbrannte Keys (2026-09-14)

docs/portainer-upgrade-20260828/preupgrade-state.json war ein committeter Volldump des
Portainer-State inkl. aller Container-Env-Secrets. Damit sind folgende Keys in der Git-Historie
(+ Gitea-Remote, teils Sitzungstranskript) verbrannt und müssen rotiert werden:

API-Provider

  • ANTHROPIC_API_KEY — Stacks openclaw, oc20260307, oc-johnny2, oc-charlie
  • OPENAI_API_KEY — dieselben Stacks
  • OPENROUTER_API_KEY — openclaw
  • GEMINI_API_KEY / GOOGLE_API_KEY — mehrere Stacks
  • LITELLM_MASTER_KEY — litellm

Bots / Gateway

  • TELEGRAM_BOT_TOKEN — mehrere Stacks
  • OPENCLAW_GATEWAY_TOKEN — openclaw, openclaw2, oc20260307

Tunnel

  • CLOUDFLARE_TUNNEL_TOKEN — pve-cloudflared, ds923-cloudflared, ds415-cloudflared, cloudflared

Sonstige

  • AdGuard private_-Token — adguard/AdGuardHome.yaml + agh-bf1-AdGuardHome.snapshot.yaml
  • N8N_MCP_BEARER — docs/handoff-20260828-mcp-cleanup-und-shelly-tote.md

Quelle entfernt/redaktiert in Commit 3eb03ae. Die Keys sind trotz Löschung in der Historie → Rotation nötig.

## Ergänzung: durch Secret-Leak verbrannte Keys (2026-09-14) `docs/portainer-upgrade-20260828/preupgrade-state.json` war ein committeter Volldump des Portainer-State inkl. aller Container-Env-Secrets. Damit sind folgende Keys in der Git-Historie (+ Gitea-Remote, teils Sitzungstranskript) verbrannt und müssen rotiert werden: **API-Provider** - `ANTHROPIC_API_KEY` — Stacks openclaw, oc20260307, oc-johnny2, oc-charlie - `OPENAI_API_KEY` — dieselben Stacks - `OPENROUTER_API_KEY` — openclaw - `GEMINI_API_KEY` / `GOOGLE_API_KEY` — mehrere Stacks - `LITELLM_MASTER_KEY` — litellm **Bots / Gateway** - `TELEGRAM_BOT_TOKEN` — mehrere Stacks - `OPENCLAW_GATEWAY_TOKEN` — openclaw, openclaw2, oc20260307 **Tunnel** - `CLOUDFLARE_TUNNEL_TOKEN` — pve-cloudflared, ds923-cloudflared, ds415-cloudflared, cloudflared **Sonstige** - AdGuard `private_`-Token — `adguard/AdGuardHome.yaml` + `agh-bf1-AdGuardHome.snapshot.yaml` - `N8N_MCP_BEARER` — `docs/handoff-20260828-mcp-cleanup-und-shelly-tote.md` Quelle entfernt/redaktiert in Commit `3eb03ae`. Die Keys sind trotz Löschung in der Historie → Rotation nötig.
Author
Owner

Neuer Posten #9 vorgemerkt (2026-09-14): GITEA_ACCESS_TOKEN rotieren.

Ins Transkript geraten am 2026-09-14 (TP25-In-situ-Session) — kein Maskierungsmuster diesmal, sondern ein Fehlerpfad: Env-Parse-Fehler schob den Token in eine URL, urllib warf ValueError: unknown url type und druckte ihn im Traceback. Sechster Vorfall der Leak-Familie (#1/#5/#6/#7/#8), neue Unterklasse „Fehlerausgabe statt Maskierung".

Rotation: neu anlegen (Gitea → Settings → Applications), ~/.hermes/.env nachziehen, altes widerrufen. Konsumenten: bin/gitea-tp-sync.py + Session-Ad-hoc-API-Calls. Details + Merkregel in docs/teilprojekte.md → TP30, Tabelle Posten #9.

⚠️ Bleibt beim gebündelten Termin laut Auslösekriterium — es sei denn, das harte Ausnahme-Kriterium (fremdzugängliches Gerät o.ä.) greift; das Transkript liegt lokal auf Christophs Mac.

**Neuer Posten #9 vorgemerkt (2026-09-14): `GITEA_ACCESS_TOKEN` rotieren.** Ins Transkript geraten am 2026-09-14 (TP25-In-situ-Session) — kein Maskierungsmuster diesmal, sondern ein **Fehlerpfad**: Env-Parse-Fehler schob den Token in eine URL, `urllib` warf `ValueError: unknown url type` und druckte ihn im Traceback. Sechster Vorfall der Leak-Familie (#1/#5/#6/#7/#8), neue Unterklasse „Fehlerausgabe statt Maskierung". Rotation: neu anlegen (Gitea → Settings → Applications), `~/.hermes/.env` nachziehen, altes widerrufen. Konsumenten: `bin/gitea-tp-sync.py` + Session-Ad-hoc-API-Calls. Details + Merkregel in `docs/teilprojekte.md` → TP30, Tabelle Posten #9. ⚠️ Bleibt beim gebündelten Termin laut Auslösekriterium — es sei denn, das harte Ausnahme-Kriterium (fremdzugängliches Gerät o.ä.) greift; das Transkript liegt lokal auf Christophs Mac.
Author
Owner

Posten #12 ergänzt (2026-09-23, Claude-Desktop/OpenRouter-Session).

  • Credential: OpenRouter-API-Key (sk-or-v1-cb6…258).
  • Anlass: 🔴 ins Transkript geraten — das sed ankerte auf den geratenen Namen apiKey, der echte Schlüssel heißt inferenceGatewayApiKey ⇒ kein Match. Gleiche Familie wie #5/#10/#11, neue Unterklasse: JSON statt Env — das geteilte Snippet (([A-Z0-9_]*(…|KEY|…))=[^[:space:]]*) ist auf KEY=VALUE-Zeilen gebaut und kann "key": "…" nicht treffen.
  • Merkregel ergänzt in docs/teilprojekte.md (TP30): für JSON einen JSON-bewussten Masker benutzen; Schlüsselnamen erst auflisten, dann maskieren.
  • Konsumenten (beide müssen mit): ~/.claude-code-router/config.sqlite → Providers[].api_key (+ CCR-Neustart) und 3P-Config e1219ea4 → inferenceGatewayApiKey. 3P ist alles-oder-nichts: fehlt der Key, hat die App gar keine Modelle.
  • Status: Wert ist noch gültig (200, verifiziert via /api/v1/key) — verbrannt, aber Rotation bleibt gebündelt (kein Vorziehen, TP30-Regel).
  • Nicht gezählt: zweiter Fund derselben Session — head -c 400 auf bin/ccr-claude-code-api-key-claude-code gab den CCR-Profil-Token aus (local-only 127.0.0.1, geringe Reichweite).
**Posten #12 ergänzt** (2026-09-23, Claude-Desktop/OpenRouter-Session). - **Credential:** OpenRouter-API-Key (`sk-or-v1-cb6…258`). - **Anlass:** 🔴 ins Transkript geraten — das `sed` ankerte auf den **geratenen** Namen `apiKey`, der echte Schlüssel heißt `inferenceGatewayApiKey` ⇒ kein Match. Gleiche Familie wie #5/#10/#11, **neue Unterklasse: JSON statt Env** — das geteilte Snippet (`([A-Z0-9_]*(…|KEY|…))=[^[:space:]]*`) ist auf `KEY=VALUE`-Zeilen gebaut und kann `"key": "…"` nicht treffen. - **Merkregel ergänzt** in `docs/teilprojekte.md` (TP30): für JSON einen JSON-bewussten Masker benutzen; Schlüsselnamen erst *auflisten*, dann maskieren. - **Konsumenten (beide müssen mit):** `~/.claude-code-router/config.sqlite` → `Providers[].api_key` (+ CCR-Neustart) **und** 3P-Config `e1219ea4` → `inferenceGatewayApiKey`. 3P ist alles-oder-nichts: fehlt der Key, hat die App gar keine Modelle. - **Status:** Wert ist **noch gültig** (200, verifiziert via `/api/v1/key`) — verbrannt, aber Rotation bleibt gebündelt (kein Vorziehen, TP30-Regel). - **Nicht gezählt:** zweiter Fund derselben Session — `head -c 400` auf `bin/ccr-claude-code-api-key-claude-code` gab den CCR-Profil-Token aus (local-only `127.0.0.1`, geringe Reichweite).
Author
Owner

Posten #12 — Nachtrag 2026-09-24: Konsumenten-Inventur korrigiert (live geprüft)

Die frühere Aussage „danach zwei Konsumenten: config.sqlite + 3P-Config (inferenceGatewayApiKey)" ist so nicht mehr richtig:

  • Die angewandte 3P-Config 8f69f2f1-… („Claude Code Router", _meta.appliedId seit 2026-09-24) trägt nur den CCR-Gateway-Token (len 50, x-api-key), nicht den OpenRouter-Key. Gegen CCR getestet: HTTP 200 — die App authentifiziert sich damit.
  • Der OpenRouter-Key lebt real in ~/.claude-code-router/config.sqlite (Providers[0].api_key, live von CCR benutzt) und in der nur gespeicherten, nicht angewandten Config e1219ea4-… (len 73, sha f23aaebdaa4c).

Rotation also: neuen Key in config.sqlite → Providers[0].api_key schreiben, CCR-App neu starten (CCR liest seine Config nur beim Start — PUT /manager/config ist gesperrt), e1219ea4 löschen/ersetzen. 8f69f2f1 bleibt unangetastet.

Nebenfund: CCR regeneriert die 3P-Config 8f69f2f1 bei jedem App-Start (Modell-Liste, Hex-Aliase, appliedId) — Handedits dort sind flüchtig, die SSoT ist config.sqlite.

**Posten #12 — Nachtrag 2026-09-24: Konsumenten-Inventur korrigiert (live geprüft)** Die frühere Aussage „danach zwei Konsumenten: `config.sqlite` + 3P-Config (`inferenceGatewayApiKey`)" ist so **nicht mehr richtig**: - Die **angewandte** 3P-Config `8f69f2f1-…` („Claude Code Router", `_meta.appliedId` seit 2026-09-24) trägt **nur den CCR-Gateway-Token** (len 50, `x-api-key`), **nicht** den OpenRouter-Key. Gegen CCR getestet: **HTTP 200** — die App authentifiziert sich damit. - Der **OpenRouter-Key** lebt real in **`~/.claude-code-router/config.sqlite`** (`Providers[0].api_key`, live von CCR benutzt) **und** in der nur *gespeicherten*, **nicht** angewandten Config `e1219ea4-…` (len 73, sha `f23aaebdaa4c`). **Rotation also:** neuen Key in `config.sqlite` → `Providers[0].api_key` schreiben, **CCR-App neu starten** (CCR liest seine Config nur beim Start — `PUT /manager/config` ist gesperrt), `e1219ea4` löschen/ersetzen. `8f69f2f1` bleibt **unangetastet**. **Nebenfund:** CCR **regeneriert** die 3P-Config `8f69f2f1` bei jedem App-Start (Modell-Liste, Hex-Aliase, `appliedId`) — Handedits dort sind flüchtig, die SSoT ist `config.sqlite`.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: admin/bf-infra#20