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
.env.example
+9 -41
View File
@@ -20,49 +20,17 @@ HERMES_GATEWAY_PORT=8447
HERMES_UID=10000 HERMES_UID=10000
HERMES_GID=10000 HERMES_GID=10000
# NICHT MEHR NOETIG im Normalbetrieb (seit dem Caddy-Umbau, 19.07.2026 spaeter # HERMES_DASHBOARD_USER ist der Login-Username fuer Caddys Basic-Auth vor dem
# Abend): das Dashboard bindet nur noch auf 127.0.0.1, Hermes' eigenes # Dashboard (siehe CADDY_BASIC_AUTH_HASH unten) — Klartext, frei waehlbar.
# Auth-Gate engagiert sich laut eigener Fehlermeldung NUR bei einem 0.0.0.0- # Kein Hermes-eigener Auth-Provider mehr noetig: das Dashboard bindet fest auf
# Bind. Caddy (siehe CADDY_BASIC_AUTH_HASH unten) macht die eigentliche # 127.0.0.1, Hermes' eingebautes Auth-Gate engagiert sich laut eigener
# Absicherung nach aussen. Einfach leer lassen. # Fehlermeldung nur bei einem 0.0.0.0-Bind, greift hier also gar nicht.
#
# Nur falls der Dashboard-Bind mal wieder auf 0.0.0.0 gestellt wird, ist ein
# Wert hier noetig (sonst verweigert Hermes den Start hart mit "no auth
# providers are registered") — dann zusaetzlich den dashboard:-Block in
# hermes-agent-config/config.yaml.example (bzw. der echten config.yaml)
# einkommentieren. HERMES_DASHBOARD_USER ist Klartext (frei waehlbar),
# HERMES_DASHBOARD_PASSWORD_HASH ist NIEMALS das Klartext-Passwort, sondern
# der Hash daraus. Erzeugen (einmalig, 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'))"
# Den Output (nicht das Passwort selbst!) hier eintragen.
#
# ACHTUNG DOLLARZEICHEN-FALLE falls Du's doch brauchst: der erzeugte Hash hat
# das Format "pbkdf2:sha256:<n>$<salt>$<hash>" - also ZWEI rohe "$"-Zeichen
# drin. Docker Compose interpretiert "$xyz" in .env-Werten selbst als
# Variablen-Referenz und ersetzt nicht aufloesbare Teile stillschweigend
# durch Leerstring (sichtbar als "WARN The "xyz" variable is not set"
# beim "docker-compose up"). Ergebnis: ein verstuemmelter Hash, das
# Dashboard startet trotzdem nicht ("no auth providers are registered"),
# obwohl alles "richtig" eingetragen aussieht.
# FIX: jedes einzelne "$" im Hash durch "$$" ersetzen bevor Du ihn hier
# eintraegst, z.B. aus
# pbkdf2:sha256:260000$f2kwriK6aYVRG5$BRps7npu2Tzg...
# wird
# pbkdf2:sha256:260000$$f2kwriK6aYVRG5$$BRps7npu2Tzg...
# Am schnellsten mit dem sed-Trick:
# sed -i '/^HERMES_DASHBOARD_PASSWORD_HASH=/ s/\$/$$/g' .env
HERMES_DASHBOARD_USER=admin HERMES_DASHBOARD_USER=admin
HERMES_DASHBOARD_PASSWORD_HASH=
# Seit 19.07.2026, spaeter Abend: Caddy (Service "caddy" in docker-compose.yml) # Caddy (Service "caddy" in docker-compose.yml) macht TLS-Termination auf Port
# macht TLS-Termination auf Port 443 + eine EIGENE Basic-Auth-Schicht vor dem # 443 + eine eigene Basic-Auth-Schicht vor dem Dashboard (das selbst nur noch
# Dashboard (das selbst nur noch auf 127.0.0.1 bindet). Selber HERMES_DASHBOARD_USER # auf 127.0.0.1 bindet). Nutzt HERMES_DASHBOARD_USER von oben als Login-Name,
# wie oben, aber ein EIGENER Hash noetig — Caddy will bcrypt, Hermes' Hash ist # aber einen eigenen Hash — Caddy will bcrypt. Erzeugen (einmalig):
# pbkdf2, die Formate sind nicht austauschbar. Erzeugen (einmalig, gleiches
# Klartext-Passwort wie beim Dashboard-Hash oben verwenden, muss aber nicht):
# docker run --rm caddy:2-alpine caddy hash-password --plaintext 'DEIN-PASSWORT' # docker run --rm caddy:2-alpine caddy hash-password --plaintext 'DEIN-PASSWORT'
# Output hier eintragen. # Output hier eintragen.
# #
README.md
+44 -51
View File
@@ -28,9 +28,13 @@ hermes-agent (Nous Research, network_mode: host)
v v
Anthropic (ueber deine Claude-Max-Subscription) Anthropic (ueber deine Claude-Max-Subscription)
hermes-agent-dashboard (0.0.0.0:9119, Hermes' eigenes Web-UI/Setup, per hermes-agent-dashboard (127.0.0.1:9119, Hermes' eigenes Web-UI/Setup, nur
Basic-Auth gesichert seit 19.07.2026 — Stefans intern erreichbar)
Entscheidung, siehe Sicherheitshinweis) ^
| reverse_proxy
v
caddy (0.0.0.0:443, TLS + Basic-Auth — einzige Auth-/TLS-Schicht,
siehe Sicherheitshinweis)
``` ```
Warum das Gateway trotzdem noch da ist, obwohl alles auf einer Maschine Warum das Gateway trotzdem noch da ist, obwohl alles auf einer Maschine
@@ -83,28 +87,18 @@ aussen — kein anderer Rechner kommt mehr direkt ran.
beim Config-Laden aus den Container-Env-Vars expandiert, die kommen aus beim Config-Laden aus den Container-Env-Vars expandiert, die kommen aus
Deiner `.env`. Kein manuelles Ausfuellen noetig. Deiner `.env`. Kein manuelles Ausfuellen noetig.
4. **Dashboard-Auth: NICHT mehr noetig, ueberspringen.** (Historie: war 4. **TLS-Reverse-Proxy (Caddy) einrichten — macht Port 443 von aussen
zwischenzeitlich Pflicht, solange `hermes-agent-dashboard` mit `--host
0.0.0.0` lief — Hermes verweigert diesen Bind hart ohne registrierten
Auth-Provider: `Refusing to bind dashboard to 0.0.0.0 — the auth gate
engages on non-loopback binds, but no auth providers are registered`.
Seit Schritt 5 unten (Caddy) bindet das Dashboard aber nur noch auf
`127.0.0.1` — Hermes' Auth-Gate engagiert sich laut eigener Fehlermeldung
NUR bei einem 0.0.0.0-Bind, hier greift's also gar nicht. Caddy macht die
eigentliche Absicherung nach aussen. `HERMES_DASHBOARD_USER`/
`_PASSWORD_HASH` in `.env` koennen leer bleiben, kein Hash-Erzeugen mehr
noetig.)
Nur falls Du den Dashboard-Bind mal wieder direkt auf `0.0.0.0` stellst
(z.B. um ohne Caddy zu testen), brauchst Du das wieder — dann in
`hermes-agent-config/config.yaml.example` (bzw. Deiner echten
`config.yaml`) den auskommentierten `dashboard:`-Block reaktivieren und
`HERMES_DASHBOARD_PASSWORD_HASH` in `.env` setzen (Anleitung dazu direkt
im Kommentar über dem Block, inkl. Dollarzeichen-Escaping-Falle).
5. **TLS-Reverse-Proxy (Caddy) einrichten — macht Port 443 von aussen
erreichbar, Dashboard bleibt intern auf `127.0.0.1`:** erreichbar, Dashboard bleibt intern auf `127.0.0.1`:**
Hermes' eigenes Dashboard-Auth-Gate (`dashboard.basic_auth` in
`config.yaml` + `HERMES_DASHBOARD_PASSWORD_HASH`) ist bewusst NICHT mehr
Teil des Setups (aufgeraeumt am 19.07.2026, spaeter Abend/20.07.2026) —
das Gate engagiert sich laut eigener Fehlermeldung ohnehin nur bei einem
`0.0.0.0`-Bind, und der Dashboard-Container bindet fest auf `127.0.0.1`
(siehe `command:` im `hermes-agent-dashboard`-Service). Die komplette
Absicherung nach aussen laeuft ausschliesslich ueber Caddy unten —
ein Auth-Layer statt zwei, weniger Setup-Schritte, weniger Verwirrung.
a. Selbstsigniertes Zertifikat, 100 Jahre gueltig (bewusst kein Let's a. Selbstsigniertes Zertifikat, 100 Jahre gueltig (bewusst kein Let's
Encrypt — kein Domain-/Port-80-Zwang, kein Renewal je wieder noetig). Encrypt — kein Domain-/Port-80-Zwang, kein Renewal je wieder noetig).
**Erzeugt sich automatisch** — kein manueller Schritt mehr noetig: der **Erzeugt sich automatisch** — kein manueller Schritt mehr noetig: der
@@ -128,21 +122,22 @@ aussen — kein anderer Rechner kommt mehr direkt ran.
-subj "/CN=hermes-dashboard" -subj "/CN=hermes-dashboard"
``` ```
b. Caddy-Basic-Auth-Hash erzeugen (EIGENER Hash, nicht derselbe wie bei b. Caddy-Basic-Auth-Hash erzeugen (bcrypt, das einzige Auth-Secret das es
Schritt 4 — Caddy will bcrypt, Hermes' Hash ist pbkdf2): jetzt noch braucht):
```bash ```bash
docker run --rm caddy:2-alpine caddy hash-password --plaintext 'DEIN-PASSWORT' docker run --rm caddy:2-alpine caddy hash-password --plaintext 'DEIN-PASSWORT'
``` ```
Output in `.env` bei `CADDY_BASIC_AUTH_HASH` eintragen, danach — Output in `.env` bei `CADDY_BASIC_AUTH_HASH` eintragen, danach —
**gleiche Dollarzeichen-Falle wie bei Schritt 4** (bcrypt-Hashes haben **Dollarzeichen-Falle** (bcrypt-Hashes haben rohe `$`-Zeichen drin,
auch rohe `$`-Zeichen drin) — escapen: Docker Compose interpretiert `$xyz` in `.env`-Werten sonst als eigene
Variablen-Referenz und ersetzt still durch Leerstring) — escapen:
```bash ```bash
sed -i '/^CADDY_BASIC_AUTH_HASH=/ s/\$/$$/g' .env sed -i '/^CADDY_BASIC_AUTH_HASH=/ s/\$/$$/g' .env
``` ```
`HERMES_DASHBOARD_USER` aus Schritt 4 wird wiederverwendet (dasselbe `HERMES_DASHBOARD_USER` aus Schritt 2 (`.env`) wird als Login-Name
Login gilt fuer beide Auth-Schichten). wiederverwendet.
6. **Stack starten:** 5. **Stack starten:**
```bash ```bash
docker compose up -d docker compose up -d
``` ```
@@ -150,18 +145,17 @@ aussen — kein anderer Rechner kommt mehr direkt ran.
paar Minuten), startet dann `hermes-proxy`, `hermes-gateway`, paar Minuten), startet dann `hermes-proxy`, `hermes-gateway`,
`hermes-agent` (Gateway/Messaging-Prozess), `hermes-agent-dashboard` und `hermes-agent` (Gateway/Messaging-Prozess), `hermes-agent-dashboard` und
`caddy`. Falls `CADDY_BASIC_AUTH_HASH` noch leer ist: `caddy` bricht beim `caddy`. Falls `CADDY_BASIC_AUTH_HASH` noch leer ist: `caddy` bricht beim
Start ab, die anderen laufen trotzdem — Wert nachtragen (Schritt 5b), dann Start ab, die anderen laufen trotzdem — Wert nachtragen (Schritt 4b), dann
`docker compose up -d caddy`. `HERMES_DASHBOARD_PASSWORD_HASH` darf leer `docker compose up -d caddy`.
bleiben (siehe Schritt 4).
7. **Einmalig Claude-CLI-Login** (oeffnet Browser-OAuth mit deiner Claude-Max-Subscription): 6. **Einmalig Claude-CLI-Login** (oeffnet Browser-OAuth mit deiner Claude-Max-Subscription):
```bash ```bash
docker exec -it hermes-proxy claude docker exec -it hermes-proxy claude
``` ```
Danach liegen die Credentials persistent in `hermes-data/claude-config/` Danach liegen die Credentials persistent in `hermes-data/claude-config/`
— ueberlebt Container-Restarts. — ueberlebt Container-Restarts.
8. **Testen, dass der Proxy laeuft:** 7. **Testen, dass der Proxy laeuft:**
```bash ```bash
curl -s http://127.0.0.1:${HERMES_GATEWAY_PORT:-8447}/v1/chat/completions \ curl -s http://127.0.0.1:${HERMES_GATEWAY_PORT:-8447}/v1/chat/completions \
-H "Content-Type: application/json" \ -H "Content-Type: application/json" \
@@ -170,7 +164,7 @@ aussen — kein anderer Rechner kommt mehr direkt ran.
``` ```
Ohne oder mit falschem Bearer-Token gibt's `401 unauthorized`. Ohne oder mit falschem Bearer-Token gibt's `401 unauthorized`.
9. **Mit Hermes chatten:** 8. **Mit Hermes chatten:**
```bash ```bash
docker exec -it hermes-agent hermes chat docker exec -it hermes-agent hermes chat
``` ```
@@ -179,7 +173,7 @@ aussen — kein anderer Rechner kommt mehr direkt ran.
beim ersten Aufruf "Zertifikat nicht vertrauenswuerdig" (weil selbstsigniert, beim ersten Aufruf "Zertifikat nicht vertrauenswuerdig" (weil selbstsigniert,
nicht von einer oeffentlichen CA) — einmalig als Ausnahme akzeptieren nicht von einer oeffentlichen CA) — einmalig als Ausnahme akzeptieren
("Trotzdem fortfahren" o.ae.), danach fragt Caddy den Basic-Auth-Login aus ("Trotzdem fortfahren" o.ae.), danach fragt Caddy den Basic-Auth-Login aus
Schritt 5b ab. Traffic ist ab hier durchgehend TLS-verschluesselt, kein Schritt 4b ab. Traffic ist ab hier durchgehend TLS-verschluesselt, kein
SSH-Tunnel mehr noetig. SSH-Tunnel mehr noetig.
## Mobiler Client (Android)? ## Mobiler Client (Android)?
@@ -203,18 +197,17 @@ Zwei GRUNDVERSCHIEDENE Richtungen, nicht verwechseln:
ran, solange Du nicht selbst was aendertst (z.B. fuer den mobilen API-Server ran, solange Du nicht selbst was aendertst (z.B. fuer den mobilen API-Server
oben, oder falls Hermes doch mal auf eine zweite Maschine zieht). oben, oder falls Hermes doch mal auf eine zweite Maschine zieht).
`hermes-agent-dashboard` bindet seit dem 19.07.2026, spaeter Abend, wieder `hermes-agent-dashboard` bindet fest auf `127.0.0.1` — von aussen nicht mehr
auf `127.0.0.1` — von aussen nicht mehr direkt erreichbar. Davor steht seitdem direkt erreichbar. Davor steht `caddy` (Service in `docker-compose.yml`,
`caddy` (Service in `docker-compose.yml`, Config in `Caddyfile`): terminiert Config in `Caddyfile`): terminiert TLS auf Port 443 mit einem selbstsignierten
TLS auf Port 443 mit einem selbstsignierten 100-Jahre-Zertifikat (Setup-Schritt 100-Jahre-Zertifikat (Setup-Schritt 4a) und erzwingt eine Basic-Auth-Schicht
5a) und erzwingt eine EIGENE Basic-Auth-Schicht (Setup-Schritt 5b, eigener (Setup-Schritt 4b, bcrypt-Hash in `CADDY_BASIC_AUTH_HASH`). Caddy ist die
bcrypt-Hash in `CADDY_BASIC_AUTH_HASH` — nicht derselbe wie Hermes' pbkdf2-Hash). EINZIGE Auth-/TLS-Schicht — Hermes' eigenes Dashboard-Auth-Gate
Zwei Gruende fuer die doppelte Auth statt nur auf Hermes' eigene zu vertrauen: (`dashboard.basic_auth`/`HERMES_DASHBOARD_PASSWORD_HASH`) wurde bewusst
1. Hermes' Auth-Gate "engagiert" laut eigener Fehlermeldung nur bei einem komplett rausgenommen (aufgeraeumt 20.07.2026): es engagiert sich laut eigener
0.0.0.0-Bind — auf 127.0.0.1 (das Caddy anspricht) ist nicht garantiert, Fehlermeldung ohnehin nur bei einem 0.0.0.0-Bind, der Dashboard-Container
dass `dashboard.basic_auth` noch durchgesetzt wird. bindet aber fest auf 127.0.0.1 — ein zweiter, nie greifender Auth-Layer haette
2. Selbst wenn doch: zwei unabhaengige Schichten sind ohnehin robuster als nur Setup-Schritte und Verwirrung gekostet, ohne echten Sicherheitsgewinn.
eine, falls in Zukunft mal eine davon falsch konfiguriert wird.
Das war vorher (kurzzeitig, testweise) `0.0.0.0` OHNE TLS — Passwort ging als Das war vorher (kurzzeitig, testweise) `0.0.0.0` OHNE TLS — Passwort ging als
Basic-Auth im Klartext raus. Ist jetzt behoben: einziger von aussen offene Basic-Auth im Klartext raus. Ist jetzt behoben: einziger von aussen offene
@@ -222,7 +215,7 @@ Port ist 443, durchgehend verschluesselt.
Das Zertifikat ist selbstsigniert (keine oeffentliche CA dahinter) — Browser Das Zertifikat ist selbstsigniert (keine oeffentliche CA dahinter) — Browser
zeigen beim ersten Aufruf eine Warnung, die Du einmalig als Ausnahme zeigen beim ersten Aufruf eine Warnung, die Du einmalig als Ausnahme
akzeptierst (Details siehe Setup-Schritt 9). Wer eine "echte", warnungsfreie akzeptierst (Details siehe Setup-Schritt 8). Wer eine "echte", warnungsfreie
CA-Kette will, braucht dafuer eine oeffentliche Domain + Let's Encrypt — war CA-Kette will, braucht dafuer eine oeffentliche Domain + Let's Encrypt — war
hier bewusst nicht der Plan. hier bewusst nicht der Plan.
@@ -240,7 +233,7 @@ Caddy-Reverse-Proxy davorschalten.
(`config.yaml`, aus `hermes-agent-config/config.yaml.example` geseedet), (`config.yaml`, aus `hermes-agent-config/config.yaml.example` geseedet),
Sessions, Memory, Skills, `.env` Sessions, Memory, Skills, `.env`
- `hermes-data/caddy-certs/` — selbstsigniertes 100-Jahre-Zertifikat - `hermes-data/caddy-certs/` — selbstsigniertes 100-Jahre-Zertifikat
(`dashboard.crt`/`dashboard.key`, Setup-Schritt 5a) — Private Key, niemals (`dashboard.crt`/`dashboard.key`, Setup-Schritt 4a) — Private Key, niemals
committen committen
- `hermes-data/caddy-data/`, `hermes-data/caddy-config/` — Caddys eigener - `hermes-data/caddy-data/`, `hermes-data/caddy-config/` — Caddys eigener
Runtime-State (nicht von Dir angefasst) Runtime-State (nicht von Dir angefasst)
docker-compose.yml
+16 -21
View File
@@ -187,18 +187,13 @@ services:
environment: environment:
- HERMES_UID=${HERMES_UID:-10000} - HERMES_UID=${HERMES_UID:-10000}
- HERMES_GID=${HERMES_GID:-10000} - HERMES_GID=${HERMES_GID:-10000}
# NICHT MEHR PFLICHT seit dem Caddy-Umbau (19.07.2026, spaeter Abend): # HERMES_DASHBOARD_USER wird hier NICHT fuer Hermes' eigenes Auth-Gate
# Hermes' eigenes Auth-Gate "engagiert sich" laut seiner eigenen # gebraucht (das Gate engagiert sich laut eigener Fehlermeldung nur bei
# Fehlermeldung NUR bei einem 0.0.0.0-Bind ("the auth gate engages on # einem 0.0.0.0-Bind, der Service unten bindet aber fest auf 127.0.0.1
# non-loopback binds"). Der Service unten bindet per `command:` auf # per `command:`) — steht nur der Vollstaendigkeit halber mit drin,
# 127.0.0.1 — das Gate greift also gar nicht, Caddy (siehe unten) macht # tatsaechlich genutzt wird die Variable von Caddy (siehe unten) fuer
# die eigentliche Absicherung nach aussen (TLS + eigene Basic-Auth). # dessen Basic-Auth. Absicherung nach aussen laeuft komplett ueber Caddy.
# HERMES_DASHBOARD_PASSWORD_HASH ist daher optional: leer lassen ist ok,
# kein Hash-Erzeugen mehr noetig fuer den Normalbetrieb. Nur falls der
# Dashboard-Bind mal wieder auf 0.0.0.0 wandert, braucht's wieder einen
# Wert (siehe .env.example fuer die Erzeugung).
- HERMES_DASHBOARD_USER=${HERMES_DASHBOARD_USER:-admin} - HERMES_DASHBOARD_USER=${HERMES_DASHBOARD_USER:-admin}
- HERMES_DASHBOARD_PASSWORD_HASH=${HERMES_DASHBOARD_PASSWORD_HASH:-}
# Kurskorrektur 19.07.2026, spaeter Abend: Stefan wollte erst 0.0.0.0 # Kurskorrektur 19.07.2026, spaeter Abend: Stefan wollte erst 0.0.0.0
# (SSH-Tunnel machte mit SSL Probleme), jetzt aber die richtige Loesung: # (SSH-Tunnel machte mit SSL Probleme), jetzt aber die richtige Loesung:
# Dashboard bleibt auf 127.0.0.1 (Hermes' eigenes Auth-Gate verlangt dann # Dashboard bleibt auf 127.0.0.1 (Hermes' eigenes Auth-Gate verlangt dann
@@ -210,16 +205,16 @@ services:
# ─── Caddy (TLS-Reverse-Proxy + Basic-Auth vor dem Dashboard) ────────── # ─── Caddy (TLS-Reverse-Proxy + Basic-Auth vor dem Dashboard) ──────────
# Stefans Entscheidung 19.07.2026: Dashboard bleibt intern auf 127.0.0.1, # Stefans Entscheidung 19.07.2026: Dashboard bleibt intern auf 127.0.0.1,
# Caddy uebernimmt TLS-Termination auf Port 443 UND eine zweite Basic-Auth- # Caddy uebernimmt TLS-Termination auf Port 443 UND die Basic-Auth davor.
# Schicht davor. Der zweite Punkt ist kein Overkill, sondern noetig: Hermes' # Caddy ist die EINZIGE Auth-/TLS-Schicht (aufgeraeumt 20.07.2026): Hermes'
# eigenes Auth-Gate "engagiert" laut seiner eigenen Fehlermeldung NUR bei # eigenes Dashboard-Auth-Gate (dashboard.basic_auth) wurde komplett entfernt,
# einem 0.0.0.0-Bind. Auf 127.0.0.1 (das Caddy hier anspricht) ist unklar/ # weil es sich laut eigener Fehlermeldung ohnehin nur bei einem 0.0.0.0-Bind
# nicht garantiert, ob dashboard.basic_auth trotzdem noch durchgesetzt wird # engagiert — der Dashboard-Container bindet aber fest auf 127.0.0.1, das
# - deshalb sichert Caddy selbst zusaetzlich ab, statt sich darauf zu # Gate haette hier nie gegriffen. Ein zweiter, nie greifender Auth-Layer
# verlassen. Nutzt denselben HERMES_DASHBOARD_USER wie Hermes (aus .env), # haette nur Setup-Schritte gekostet, kein Sicherheitsgewinn. Nutzt
# aber einen EIGENEN Hash: Caddys basic_auth will bcrypt, Hermes' Hash ist # HERMES_DASHBOARD_USER (aus .env) als Login-Name + einen eigenen bcrypt-
# pbkdf2 — Formate sind nicht kompatibel, siehe .env.example fuer die # Hash in CADDY_BASIC_AUTH_HASH (Caddy verlangt bcrypt, siehe .env.example
# Erzeugung von CADDY_BASIC_AUTH_HASH. # fuer die Erzeugung).
# #
# Zertifikat: bewusst KEIN Let's Encrypt (bräuchte oeffentliche Domain + # Zertifikat: bewusst KEIN Let's Encrypt (bräuchte oeffentliche Domain +
# Port-80-Challenge). Stefans Wunsch: ein selbstsigniertes Zertifikat mit # Port-80-Challenge). Stefans Wunsch: ein selbstsigniertes Zertifikat mit
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. # (den Hermes intern nutzt) setzt den Header automatisch aus diesem Feld.
api_key: "${HERMES_GATEWAY_TOKEN}" api_key: "${HERMES_GATEWAY_TOKEN}"
# ─── Dashboard-Auth (standardmaessig AUSKOMMENTIERT) ──────────────────── # Kein dashboard.basic_auth-Block mehr hier: Hermes' eigenes Auth-Gate
# Hermes' eigenes Auth-Gate verweigert den Bind des Dashboards auf 0.0.0.0 # engagiert sich laut eigener Fehlermeldung nur bei einem 0.0.0.0-Bind. Das
# komplett, wenn kein Auth-Provider registriert ist ("Refusing to bind # Dashboard bindet in docker-compose.yml fest auf 127.0.0.1 (command:), der
# dashboard to 0.0.0.0 — the auth gate engages on non-loopback binds, but # Caddy-Reverse-Proxy davor (TLS + eigene Basic-Auth) uebernimmt die
# no auth providers are registered") — greift aber laut derselben Meldung # komplette Absicherung nach aussen. Falls der Dashboard-Bind je wieder auf
# NUR bei einem 0.0.0.0-Bind. Unser docker-compose.yml bindet das Dashboard # 0.0.0.0 gestellt wird, blockt Hermes den Start hart ab ("no auth providers
# bewusst auf 127.0.0.1 und stellt es per Caddy-Reverse-Proxy (TLS + eigene # are registered") — das ist dann ein Signal, den Bind zurueckzustellen statt
# Basic-Auth) nach aussen bereit — das Gate hier engagiert sich dabei gar # hier einen Auth-Provider nachzuruesten.
# 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}"