# SSH-Key-Verteilung an Sub-Agenten (24.08.2026) ## Ausgangssituation Master (VPSHermes, 172.24.196.119) hatte **keinen SSH-Schlüssel**: ``` /root/.ssh/id_ed25519 → fehlt (generiert 22.08.2026) /root/.ssh/authorized_keys → 3 Keys (eingehend von Sub-Agenten) ``` Alle 3 Sub-Agenten waren **nicht per SSH erreichbar**: `Permission denied (publickey,password)` Ping und Port 22 waren offen → SSH-Daemon läuft, aber Key-Only-Auth blockiert. ## Schritt 1: SSH-Key generieren (auf Master) ```bash ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N "" -C "mesh-master@172.24.196.119" ``` **Public Key (in Tasks verteilt):** ``` ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILEn0Vb4KKwbNI5wiT+Z7VWIiY6iiO7F4BeWS2gMWPCP mesh-master@172.24.196.119 ``` ## Schritt 2: NFS-Tasks in `offen/` ablegen 3 Tasks mit Type `AcceptMasterKey` wurden in `/srv/work/tasks/offen/` abgelegt: - `20260822.34.142.AcceptMasterKey.json` → UnraidHermes - `20260822.20.26.AcceptMasterKey.json` → SwitchHermes - `20260822.178.202.AcceptMasterKey.json` → LaptopHermes **Problem:** Sub-Agenten analysierten die Tasks (10+ Zeilen Erklärung) statt die Shell-Befehle auszuführen. `execute_code` Sandbox hat kein `terminal()`. Tasks mussten mehrfach umgeschrieben werden von "Kontext+Erklärung" → reiner Befehl. **Format-Erkenntnis:** Tasks MÜSSEN das Format haben: ```json { "aufgabentyp": "terminal", "befehl": "mkdir -p ~/.ssh && echo '' >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys" } ``` Auch das scheiterte — Sub-Agenten ignorieren `befehl`-Feld wenn zu viel Kontext drumherum. ## Schritt 3: Manuelle Ausführung durch Nutzer Nutzer loggte sich auf jedem Sub-Agenten ein und führte **2 Befehle** pro Agent aus: ### Befehl 1: SSH-Key akzeptieren (identisch auf allen 3) ```bash mkdir -p ~/.ssh && chmod 700 ~/.ssh echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILEn0Vb4KKwbNI5wiT+Z7VWIiY6iiO7F4BeWS2gMWPCP mesh-master@172.24.196.119" >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ``` ### Befehl 2: Modell setzen (abhängig vom Agenten) | Agent | Befehl | |-------|--------| | UnraidHermes | `hermes config set model.default google/gemini-2.5-flash:free` | | SwitchHermes | `hermes config set model.default nvidia/nemotron-3-ultra-550b-a55b:free` | | LaptopHermes | `hermes config set model.default google/gemini-2.5-flash:free` | **Ausnahme:** SwitchHermes hatte `hermes` nicht in $PATH. Folgender Befehl war nötig: ```bash /home/mehlzoerwer/.local/bin/hermes config set model.default nvidia/nemotron-3-ultra-550b-a55b:free ``` → Immmer absoluten Pfad bei SSH-Befehlen nutzen! ## Schritt 4: SSH-Funktionstest ```bash for ip in 172.24.34.142 172.24.20.26 172.24.178.202; do ssh -o BatchMode=yes -o ConnectTimeout=5 "mehlzoerwer@$ip" "echo OK" done ``` ### Ergebnis nach Nutzer-Ausführung (28.08.2026, 20:37 CEST) | Agent | IP | SSH | Modell | |-------|----|-----|--------| | UnraidHermes | 172.24.34.142 | ✅ | google/gemini-2.5-flash:free | | SwitchHermes | 172.24.20.26 | ✅ | nvidia/nemotron-3-ultra-550b-a55b:free | | LaptopHermes | 172.24.178.202 | ✅ | google/gemini-2.5-flash:free | ## Schritt 5: Cron-Job auf LaptopHermes pinnen Nach Modell-Wechsel hatte LaptopHermes einen Drift-Fehler im Cron-Job: - Alter Snapshot: `poolside/laguna-xs-2.1:free` - Neues Modell: `google/gemini-2.5-flash:free` - Fix per SSH: ```bash ssh mehlzoerwer@172.24.178.202 \ "/home/mehlzoerwer/.local/bin/hermes cron edit ea689b6d8484 \ --provider openrouter --model google/gemini-2.5-flash:free" ``` ## Key-Learnings (in Skill-Pitfalls übernommen) 1. **SSH-Key auf Master existiert nicht von Haus aus** — muss aktiv generiert werden 2. **Sub-Agenten führen keine Shell-Befehle aus** — Tasks mit `echo >> authorized_keys` werden analysiert statt terminiert. Nutzer muss manuell eingreifen (Henne-Ei). 3. **hermes nicht in $PATH auf Sub-Agenten** — immer `/home/mehlzoerwer/.local/bin/hermes` nutzen 4. **Cron-Job-Drift nach Modell-Wechsel** — unpinned Jobs schlagen mit RuntimeError fehl, müssen per `hermes cron edit` aufs neue Modell gepinnt werden. 5. **Lange Tasks → Analyse, Kurze Befehle × Ausführung**.