DSH VPS — Rotation des cles API et incident « API key is invalid »

Instance auteur : hermes-nyora Date : 2026-08-25 Tags : dsh, vps-contabo, docker, secrets, rotation, bifrost, opencode Statut : clos — rotation complete, revocation confirmee, tour UI web verifie au vert

Contexte

Rotation des deux cles du dsh-vps (VK Bifrost sk-bf-37*** + cle OpenCode Zen sk-DWb***) apres double exposition : passage par canal de chat (Telegram) ET commit initial du depot bolbol/dsh-vps (22a18ae) embarquant les valeurs reelles en fallback heredoc de entrypoint.sh et en dur dans docker-compose.yml.

Rotation executee par Nabil via script local (saisie read -s, valeurs jamais passees par un canal) : ecriture atomique de $DSH_HOME/.credentials.yaml (volume dsh_vps_home) + .env projet.

L'incident (25/08)

Apres rotation : « This turn failed — API key is invalid » dans l'UI web DSH, alors que tous les fichiers de configuration semblaient a jour.

Diagnostic structure (mission Gemini, cadrage hermes-nyora, 3 hypotheses a discriminer) :

Hypothese	Test	Verdict
H1 session navigateur perimee	sonde headless echouait aussi (401 AuthError)	eliminee
H2 process demarre avant la rotation	StartedAt conteneur < rotation, ENV conteneur = anciennes cles	confirnee partielle
H3 residus de configuration	cles revoquees EN DUR dans `docker-compose.yml` hote + `entrypoint.sh`	cause racine

Piege de verification central : le depot Gitea montrait les valeurs tronquees (sk-bf-...e9d4, sanitisation manuelle lors du commit) mais le fichier REEL sur l'hote portait les cles completes. Les preuves du premier rapport portaient sur le repo, le runtime lisait l'hote.

Fix final

Cles externalisees dans /home/dsh-agent/dsh-vps/.env (chmod 600, couvert par *.env du .gitignore), injection via env_file: (commit 7cdda5d).
Fallbacks interdits : ${VAR:-sk-reelle} remplace par ${VAR:?variable manquante} partout (commit 7cdf4c1) — le scaffold echoue bruyamment plutot que de demarrer avec une vieille valeur.
docker compose up -d --build (recreation, pas restart), prefixes ENV du conteneur verifies alignes sur .env.
verify-dsh.sh durci : process.exit explicite sur les tests node http sinon un test echoue peut passer vert (commit e9ef336).
Revocation des anciennes cles : admin Bifrost (VK) + dashboard OpenCode — confirmee par Nabil.
Validation finale : session UI web NEUVE, tour reel reussi (le symptome initial reproduit au vert).

Ce qui ne fonctionne PAS

Tentative	Resultat	Raison
`docker compose restart` apres changement de cles	anciennes vars conservees	restart ne relit NI le `.env` NI le compose
Sanitiser uniquement rapports/preuves	secrets vivants dans les fichiers scaffoldes	lire INTEGRALEMENT chaque fichier qui entre en Git
Diagnostiquer depuis des curls externes seuls	ne voit pas ce que le process charge	comparer StartedAt vs horodatages config + printenv DANS le conteneur

Regle fleet-wide associee

Posee dans context-hub (scope infra, cle secrets_rule, relue en live le 25/08) : aucune valeur de cle/secret en clair dans un message, rapport ou mail. Depot obligatoire dans /volume1/docker/.secrets-staging/<projet>.env (hors git), reference par chemin uniquement. Reproduite dans l'AGENTS.md du workspace DSH (mecanisme natif dsh-agent-instructions).

References

Depots : bolbol/dsh-vps (22a18ae → 43c5dec), bolbol/context-hub (e7f78f8, lecon coding-bp-0001)
Script de rotation : workspace/scripts/rotate-dsh-keys.sh (hermes-nyora)
Garde-fou rejouable : .agents/verify-dsh.sh (5 tests : pnpm, plugin, MCP authentifie, isolation 403, nettoyage skill mort)

3.7 KiB Raw Permalink Blame History