Aria-Software/hermes-agent
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Dashboard-Auth komplett entfernt statt nur optional: Caddy ist einzige Auth-Schicht

Browse Source 
Hermes' eigenes Auth-Gate (dashboard.basic_auth/HERMES_DASHBOARD_PASSWORD_HASH)
engagiert sich laut eigener Fehlermeldung ohnehin nur bei einem 0.0.0.0-Bind,
der Dashboard-Container bindet aber fest auf 127.0.0.1 -- das Gate haette hier
nie gegriffen. Statt es als "Fallback falls Bind mal wieder wandert" zu
behalten, jetzt sauber raus: HERMES_DASHBOARD_PASSWORD_HASH aus .env.example
und docker-compose.yml, der auskommentierte dashboard:-Block aus
config.yaml.example, README-Setup auf 8 statt 9 Schritte umnummeriert.
Caddy (TLS + eigene Basic-Auth) ist damit die einzige noetige Auth-Schicht --
ein Layer statt zwei, weniger Setup, weniger Verwirrung. Stale Kommentare im
Caddy-Compose-Block (redeten noch von "zweiter Basic-Auth-Schicht noetig weil
unklar ob dashboard.basic_auth greift") ebenfalls korrigiert.
This commit is contained in:
ARIA
2026-07-19 22:23:22 +00:00
parent b1423ffb6e
commit 3aaddc4a31
4 changed files with 77 additions and 137 deletions
Download Patch File Download Diff File Expand all files Collapse all files
hermes-agent-config/config.yaml.example
+8 -24
View File
@@ -32,27 +32,11 @@ model:
# (den Hermes intern nutzt) setzt den Header automatisch aus diesem Feld.
api_key: "${HERMES_GATEWAY_TOKEN}"
# ─── Dashboard-Auth (standardmaessig AUSKOMMENTIERT) ────────────────────
# Hermes' eigenes Auth-Gate verweigert den Bind des Dashboards auf 0.0.0.0
# komplett, wenn kein Auth-Provider registriert ist ("Refusing to bind
# dashboard to 0.0.0.0 — the auth gate engages on non-loopback binds, but
# no auth providers are registered") — greift aber laut derselben Meldung
# NUR bei einem 0.0.0.0-Bind. Unser docker-compose.yml bindet das Dashboard
# bewusst auf 127.0.0.1 und stellt es per Caddy-Reverse-Proxy (TLS + eigene
# Basic-Auth) nach aussen bereit — das Gate hier engagiert sich dabei gar
# nicht erst, dieser Block ist im Normalbetrieb also NICHT noetig.
#
# Nur falls Du den Dashboard-Bind mal direkt auf 0.0.0.0 stellst (z.B. ohne
# Caddy testen): Block unten einkommentieren + HERMES_DASHBOARD_PASSWORD_HASH
# in .env setzen. Hash EINMALIG erzeugen (NICHT das Klartext-Passwort
# committen oder in .env schreiben — nur den Hash), gegen den "hermes-agent"-
# Container, NICHT "hermes-agent-dashboard" (der braucht den Hash schon zum
# Hochfahren, Henne-Ei-Problem):
# docker exec -it hermes-agent python -c \
# "from plugins.dashboard_auth.basic import hash_password; print(hash_password('DEIN-PASSWORT'))"
# Ergebnis nach .env als HERMES_DASHBOARD_PASSWORD_HASH eintragen.
#
# dashboard:
# basic_auth:
# username: "${HERMES_DASHBOARD_USER}"
# password_hash: "${HERMES_DASHBOARD_PASSWORD_HASH}"
# Kein dashboard.basic_auth-Block mehr hier: Hermes' eigenes Auth-Gate
# engagiert sich laut eigener Fehlermeldung nur bei einem 0.0.0.0-Bind. Das
# Dashboard bindet in docker-compose.yml fest auf 127.0.0.1 (command:), der
# Caddy-Reverse-Proxy davor (TLS + eigene Basic-Auth) uebernimmt die
# komplette Absicherung nach aussen. Falls der Dashboard-Bind je wieder auf
# 0.0.0.0 gestellt wird, blockt Hermes den Start hart ab ("no auth providers
# are registered") — das ist dann ein Signal, den Bind zurueckzustellen statt
# hier einen Auth-Provider nachzuruesten.