fix: stop dashboard restart loop and harden default API server key

[santteegt]

Summary

The package was stuck in an infinite restart loop on init: the dashboard s6 service kept crashing and being respawned, flooding the logs with a Refusing to bind dashboard to 0.0.0.0 error.

• docker-compose.yml binds HERMES_DASHBOARD_HOST to 0.0.0.0 (required so hermes-agent.dappnode:8081 is reachable from the DAppNode network) and sets HERMES_DASHBOARD_INSECURE: "true".
• Upstream hardened the dashboard auth gate in June 2026 (closing a real, exploited hole where attackers scanned for --insecure --host 0.0.0.0 dashboards and used the exposed admin API to plant SSH-key-injecting MCP persistence): HERMES_DASHBOARD_INSECURE no longer bypasses the gate, and any non-loopback bind with no registered DashboardAuthProvider now hard-exits (SystemExit) instead of degrading gracefully.
• Because the dashboard service's s6 finish script treats "dashboard enabled" as "always restart on crash," that SystemExit became the infinite loop.

Separately, once the loop is fixed, the OpenAI-compatible API server (port 3000) fails to start for the same underlying reason: API_SERVER_KEY: dappnode is 8 characters, and upstream now refuses to start that endpoint with any key under 16 chars (it dispatches terminal-capable agent work, so a guessable key is RCE).

Changes

• docker-compose.yml
  • Removed the now-inert HERMES_DASHBOARD_INSECURE (accepted but ignored upstream, only produces a misleading warning).
  • Configured the bundled username/password (basic) DashboardAuthProvider with static credentials (HERMES_DASHBOARD_BASIC_AUTH_USERNAME/_PASSWORD), matching this package's existing convention of static shared secrets scoped to the DAppNode network/VPN trust boundary (see API_SERVER_KEY: dappnode, GATEWAY_ALLOW_ALL_USERS: true, and the already-unauthenticated ttyd web terminal on port 7681).
  • Pinned HERMES_DASHBOARD_BASIC_AUTH_SECRET (session-signing key) and set HERMES_DASHBOARD_BASIC_AUTH_TTL_SECONDS to 30 days, so the one login persists across container restarts instead of invalidating every boot.
  • Replaced the too-short API_SERVER_KEY: dappnode with a strong 64-char hex key so the API server actually starts.
• getting-started.md — documents the default dashboard login and how to change it.

Not included in this PR: a version bump to dappnode_package.json, and a local build-time patch (patch-dashboard-auto-sso.py) that works around the upstream regression described below by rewriting the vendored middleware.py at image-build time. Both are being held back deliberately — see the note below.

⚠️ External fix required before merging

Configuring the basic auth provider is necessary but not sufficient for a working dashboard login, due to an unrelated regression in hermes-agent itself:

hermes_cli/dashboard_auth/middleware.py's _auto_sso_response() auto-redirects any unauthenticated page load straight to the OAuth-only /auth/login route whenever exactly one auth provider is registered — but it never checks whether that provider actually supports an OAuth redirect flow. With only the basic (password-only) provider configured, this lands on BasicAuthProvider.start_login(), which unconditionally raises NotImplementedError. Result: every unauthenticated page load 500s, before the user ever reaches the working /login credential form.

This fixes the crash loop reported here (the dashboard service now starts and stays up), but a real login attempt will still 500 until the upstream regression is fixed and released.

• Tracking issue: Dashboard 500s on every page load when basic (password) auth is the only provider — auto-SSO calls start_login() on a password-only provider NousResearch/hermes-agent#55130 — "Dashboard 500s on every page load when basic (password) auth is the only provider — auto-SSO calls start_login() on a password-only provider" (opened 2026-06-29, the same day the regressing auto-SSO feature was merged).
• Most complete open fix: fix(dashboard-auth): skip auto-SSO for password providers NousResearch/hermes-agent#57797 — adds the missing supports_password guard in both _auto_sso_response and the /auth/login route itself (defense in depth against stale links), with regression tests in both directions.
• Equivalent minimal fix: fix(dashboard): don't auto-SSO password-only providers into the OAuth route NousResearch/hermes-agent#57927 — same one-line guard in _auto_sso_response alone, also with a regression test.
• Note: this bug attracted a large number of near-duplicate open issues/PRs (at least 9 issues, ~20 PRs at the time of writing) — none merged yet. #57797/#57927 above look like the most complete and are the ones worth tracking for a merge.

Recommendation: hold this PR until one of the upstream fixes above lands in a released hermes-agent version, then bump UPSTREAM_VERSION (and dappnode_package.json's version) in the same change so the dashboard is actually usable end-to-end, not just non-crashing. A local monkey-patch of the vendored middleware.py at Docker build time was considered and prototyped, but deliberately left out of this PR — patching vendored upstream source in our Dockerfile is fragile across upstream bumps and duplicates work already in flight upstream; better to wait for the real fix to ship.

Test plan

• Rebuilt the package locally via npx @dappnode/dappnodesdk build --provider http://ipfs.dappnode:5001 and confirmed the dashboard s6 service starts and stays up (no more restart loop) and the API server starts without the API_SERVER_KEY refusal.
• Install on a DAppNode and confirm http://hermes-agent.dappnode:8081 no longer loops (dashboard login itself will still 500 until the upstream fix above ships — expected per the note above).
• Once UPSTREAM_VERSION picks up the upstream fix, confirm logging in with dappnode/dappnode reaches the authenticated dashboard and the session survives a container restart.