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)

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:

{
  "aufgabentyp": "terminal",
  "befehl": "mkdir -p ~/.ssh && echo '<pubkey>' >> ~/.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)

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:

/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

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:

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)

SSH-Key auf Master existiert nicht von Haus aus — muss aktiv generiert werden
Sub-Agenten führen keine Shell-Befehle aus — Tasks mit echo >> authorized_keys werden analysiert statt terminiert. Nutzer muss manuell eingreifen (Henne-Ei).
hermes nicht in $PATH auf Sub-Agenten — immer /home/mehlzoerwer/.local/bin/hermes nutzen
Cron-Job-Drift nach Modell-Wechsel — unpinned Jobs schlagen mit RuntimeError fehl, müssen per hermes cron edit aufs neue Modell gepinnt werden.
Lange Tasks → Analyse, Kurze Befehle × Ausführung.

4.1 KiB Raw Permalink Blame History Unescape Escape