duffyduckandClaude Opus 4.8
855cc0333e
Fuer Agenten im selben Netz wie der RVS: direkt auf die interne IP verbinden (kein NAT-Hairpin ueber den externen Hostnamen), aber im TLS-Handshake den Namen praesentieren, fuer den das Caddy-Zertifikat gilt. Ohne das schickt der Client die IP als SNI -> Caddy findet kein Cert -> 'tlsv1 alert internal error'. RVS_HOST=<interne-ip> + RVS_SNI=<zert-name>. server_hostname im ssl-Context. Leeres RVS_SNI = Verhalten wie bisher. Robuster als /etc/hosts (ueberlebt Reboots, wichtig auf Live-ISOs). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ARIA Host-Agent
Ein schlanker Agent, der direkt auf einem Rechner läuft und ARIA erlaubt, diesen Rechner zu steuern — auch wenn er sonst aus dem Netz nicht erreichbar ist (hinter NAT/Firewall, kein offener Port). Der Agent verbindet sich ausgehend zum RVS (gleicher Token wie der Rest von ARIA).
Unterschied zum Satelliten: der Satellit entdeckt und steuert andere Geräte in einem LAN; der Host-Agent steuert den Rechner, auf dem er läuft.
Fähigkeiten
| Aktion | Was |
|---|---|
exec |
Shell-Kommando ausführen (optional sudo), stdout/stderr/exit |
read |
Datei lesen (Base64, mit Offset/Limit) |
write |
Datei schreiben/anhängen (Base64 oder Text) |
info |
OS, CPU/RAM/Disk-Auslastung, Uptime, IP |
screenshot |
Bildschirmfoto (X11: scrot/maim · Wayland: grim) |
ARIA nutzt diese über die Brain-Tools host_list / host_exec / host_read /
host_write / host_info / host_screenshot.
Bauen (portable Binary)
./build.sh # braucht Docker; erzeugt dist/aria-host-agent (~15 MB)
Gebaut wird in einem bullseye-Container (altes glibc), damit die Binary auf möglichst vielen Distributionen läuft.
Docker scheitert? (Live-ISO / overlayfs-Root)
Wenn build.sh mit failed to mount … overlayfs … invalid argument abbricht,
läufst du wahrscheinlich auf einem Live-System (Live-ISO). Dessen Root ist
selbst ein overlayfs, und Dockers overlay2-Treiber kann kein Overlay-auf-
Overlay stapeln. Zwei Auswege:
- Empfohlen: Binary auf einem normal installierten Linux bauen (
./build.sh) und nur die fertigedist/aria-host-agentaufs Live-System kopieren. Die Binary ist portabel — Ziel braucht weder Docker noch Python. - Nativ bauen (ohne Docker):
Achtung: nativ gebaut linkt die Binary gegen das glibc dieser Maschine — sie läuft dann nur auf Systemen mit gleichem oder neuerem glibc.
sudo apt install -y python3-pip python3-venv ./build-native.sh
Installieren
dist/aria-host-agentauf den Ziel-Rechner kopieren..env.example→.envdaneben, RVS-Zugang +CONTROL_ENABLED=trueeintragen.- Starten:
chmod +x aria-host-agent && ./aria-host-agent— oder als Dienst: siehearia-host-agent.service.
sudo
Vier Fälle, der Agent wählt automatisch:
- Agent läuft als root (z.B. systemd
User=root) → volle Rechte, kein sudo nötig. SUDO_PASSWORD=…in der.env→sudo -Smit Passwort.SUDO_NOPASSWD=true→sudo -n(Live-ISO / passwortloses sudo, z.B. Linux Mint vom Stick).- sonst → sudo-Kommandos scheitern mit klarer Meldung.
Sicherheit
- Reagiert nur auf den eigenen RVS-Raum (Token) und nur, wenn
CONTROL_ENABLED=true. - Keine offenen Ports (reiner ausgehender Client).
- Alle Kommandos werden geloggt.
- Der Agent gibt vollen Zugriff auf den Rechner — nur auf Maschinen einsetzen, denen du ARIA anvertraust.
Hinweis Screenshot
Als Systemdienst fehlt die grafische Session. Für screenshot den Agent in der
Desktop-Session starten (Autostart) oder DISPLAY/XAUTHORITY in der Unit setzen.