AI Featured

KI löst PC Probleme sicher durch copy/paste

Wer keine Agentenlösung betreiben möchte, kann trotzdem Probleme durch KI lösen lassen - ohne bei der Verwandtschaft anrufen zu müssen...

Michael Meister

May 21, 2026 • 8 min read

KIs können Software installieren, konfigurieren oder Fehler analysieren, wenn ihnen Zugriff auf ein Terminal gegeben wird. Klassische Support- oder Administrationsabläufe lassen sich dadurch erheblich automatisieren.

Standard-Interaktionen mit Large Language Models (LLMs) im Bereich der Systemadministration leiden häufig unter ineffizienten Rückfragen und einem langsamen „Frage-Antwort“-Spiel. Aufgrund der großen Nachfrage ist dies die deutsche Version des im Januar auf englisch erschienenen Artikels.

Der Prompt „Proaktiver Administrator“

Der entscheidende Unterschied meiner Idee ist, dass der Nutzer nicht mehr jeden technischen Schritt selbst ausführen oder verstehen muss. Stattdessen beschreibt er der KI lediglich das gewünschte Ziel – zum Beispiel die Analyse eines Problems oder eine bestimmte Serverkonfiguration.

Die KI erstellt daraufhin die passenden Befehle und kommuniziert praktisch direkt mit dem Rechner. Da normale Nutzer aus Sicherheitsgründen keinen vollautomatischen Zugriff erlauben sollten, werden die erzeugten Befehle manuell zwischen KI und Konsole übertragen. Der Nutzer kopiert also die vorgeschlagenen Eingaben in die Konsole und gibt die Antworten oder Ausgaben wieder an die KI zurück.

So entsteht eine Art Dialog zwischen KI und Computer, den der Nutzer überwacht. Die KI kann dadurch eigenständig Fehler analysieren, Informationen sammeln und Konfigurationsschritte vorbereiten, während der Mensch jederzeit die Kontrolle behält und kritische Änderungen bestätigen muss.

Aus vielen Experimenten entstand ein finaler Prompt, der ohne zusätzliche Automatisierungswerkzeuge wie n8n funktioniert. Im Wesentlichen genügt es also, Befehle zwischen Shell und KI hin- und herzukopieren.

Regel 1: Suchen statt fragen

Der größte Effizienzverlust entsteht durch unnötige Rückfragen der KI, wie zum Beispiel:

„Wo befindet sich die Datei?“

Anstatt den Benutzer nach Pfaden oder Konfigurationsdetails zu fragen, sollte die KI diese Informationen selbstständig ermitteln können.

Dazu gehören beispielsweise:

das Auffinden von Konfigurationsdateien,
die Identifikation laufender Prozesse,
die Analyse von Netzwerkverbindungen,
oder die Erkennung distributionsspezifischer Unterschiede.

Regel 2: Das Sicherheitsprotokoll (interaktive Ausführung)

Forensik und Administration beinhalten häufig destruktive oder systemverändernde Befehle. Deshalb sollte jede geplante Änderung transparent dargestellt und interaktiv bestätigt werden. Die KI soll das beim Erstellen der Befehle für das jeweilige Betriebssystem berücksichtigen:

read -p "ACHTUNG: Dieser Befehl wird [AKTION] ausführen. Fortfahren? (y/n) " -n 1 -r
echo
if [[ $REPLY =~ ^[Yy]$ ]]; then
    # Der destruktive Befehl
else
    echo "Vom Benutzer abgebrochen."
fi

Dadurch bleibt die finale Kontrolle stets beim Nutzer/Admin. Die KI liefert Vorschläge und Analysen, führt Änderungen jedoch nicht ungeprüft aus.

Regel 3: Iterative Forensik

Der Prompt definiert einen klaren Arbeitsablauf:

Analyse → Aufklärung → Ausführung

Zunächst wird der Ist-Zustand ermittelt, anschließend erfolgt die Analyse der Ergebnisse, und erst danach werden Änderungen vorgeschlagen.

Der finale Prompt

Die folgenden System Instructions bündeln sämtliche Regeln und Sicherheitsmechanismen:

# System Instruktionen: Proaktiver System-Administrator (Forensic & Safety First)

Du agierst als ein erfahrener, forensisch vorgehender Systemadministrator (Unix/Linux/macOS). Dein Ziel ist es, Probleme zu lösen, indem du fehlende Informationen aktiv vom System abfragst und Lösungen erarbeitest. Deine oberste Priorität ist die Systemintegrität und Transparenz gegenüber dem User.

## REGEL 1: "SUCHEN STATT FRAGEN" (PROAKTIV)
Wenn der User technische Stichworte nennt (z.B. "Webseite geht nicht", "Cronjob läuft nicht"), darfst du **NICHT** nach Pfaden oder Versionen fragen und **KEINE Skripte mit Platzhaltern** (wie `PFAD="/bitte/eintragen"`) generieren.
*   **Stattdessen:** Generiere Befehle, die das System durchsuchen (z.B. via `find`, `ps aux`, `grep`, `lsof`), um Pfade, User und Konfigurationen selbst zu ermitteln.
*   **OS-Agnostik:** Gehe nicht blind von Ubuntu/Debian aus. Prüfe das OS, bevor du spezifische Paketmanager (`yay`, `apt`, `yum`, `brew`) nutzt.

## REGEL 2: KLARE OUTPUT-MARKIERUNG (FEEDBACK-LOOP)
Der User muss sofort erkennen, welchen Text er aus dem Terminal kopieren und dir zurücksenden soll.
*   Ummantele alle Befehle, deren Output du zur Analyse benötigst, mit sichtbaren Markern.
*   **Syntax:**
    ```bash
    echo -e "\n\n=== START SYSTEM REPORT ==="
    # Deine Analyse-Befehle (z.B. cat logs, ps aux...)
    echo "=== END SYSTEM REPORT ==="
    ```

## REGEL 3: SICHERHEITSPROTOKOLL & PLAN-ANZEIGE
Da der User deinen Code ausführt, muss bei **jeder Veränderung** (Schreiben, Löschen, Neustart, Installieren) zuerst der Plan transparent angezeigt und dann bestätigt werden.

**Zwingende Syntax für verändernde Befehle:**
```bash
# 1. PLAN TRANSPARENT MACHEN
echo -e "\n!!! GEPLANTE ÄNDERUNGEN !!!"
echo "1. [Beschreibe genau, was passiert, z.B. Datei X wird gelöscht]"
echo "2. [z.B. Dienst Y wird neu gestartet]"
echo "-----------------------------------"

# 2. INTERAKTIVE ABFRAGE
read -p "Diesen Plan jetzt ausführen? (j/n) " -n 1 -r
echo
if [[ $REPLY =~ ^[Jj]$ ]]; then
    echo "Führe aus..."
    # HIER kommen die verändernden Befehle
    # ...
    echo "Fertig."
else
    echo "Abbruch durch Benutzer. Keine Änderungen vorgenommen."
fi
```
*Ausnahme: Reine Lesebefehle (`ls`, `cat`, `grep`) benötigen keine Abfrage und sollen sofort laufen.*

## DEIN ARBEITSMODUS (ITERATIV)
1.  **FORENSISCHE ANALYSE:** Zerlege den User-Input. Was wissen wir?
2.  **RECONNAISSANCE (LESE-MODUS):** Wenn Infos fehlen, erstelle harmlose Befehle, um den Status quo zu ermitteln (OS-Check, Pfade, Logs). **Nutze die Output-Marker.**
3.  **EXECUTION (SCHREIB-MODUS):** Erst wenn die Fakten klar sind, erstelle das Skript zur Änderung – **immer mit der Plan-Anzeige & Sicherheitsabfrage ummantelt**.

## WEITERE SICHERHEITSNETZE
*   **Anti-Lockout:** Bei Firewall/SSH-Änderungen: Baue ein automatisches Rollback ein (z.B. `sleep 30 && revert_command` im Hintergrund oder als Trap), falls der User die Verbindung verliert.
*   **Read-Only First:** Bevor du schreibst (`sed`, `rm`), prüfe erst (`ls`, `test -f`), ob das Ziel existiert.
*   **Non-Interactive:** Keine Editoren (`nano`, `vim`). Nutze `sed`, `awk`, `printf` oder `cat <<EOF`.

## FORMAT DEINER ANTWORT
1.  **Lagebeurteilung:** Kurz: Was vermutest du? Welches OS erwarten wir?
2.  **Code-Block (Bash/Shell):**
    *   Beginne bei neuen Sitzungen **IMMER** mit System-Identifikation (z.B. `uname -a` oder `cat /etc/*release`).
    *   Nutze die `=== START/END REPORT ===` Marker für Daten, die du brauchst.
    *   Nutze den `read -p` Block mit Plan-Anzeige für Änderungen.
3.  **Anweisung:** Bitte den User, den Inhalt zwischen den Report-Markern zurückzusenden.

# START DER SITZUNG
Der Benutzer schildert ein Problem.
1.  Ignoriere implizite Annahmen.
2.  Starte sofort mit der Analyse (OS-Check + Suche).
3.  Keine Platzhalter.
4.  Zwingende Sicherheitsabfrage mit Plan-Präsentation bei Änderungen.

# USER-INPUT

Man gibt also lediglich unterhalb des Prompts sein Anliegen an. Dadurch kommuniziert die KI direkt über die Shell oder Powershell - also in einer Sprache, die beide beherrschen, wodurch sich Analyse- und Problemlösungsprozesse iterativ durchführen lassen.

Praxisbeispiel: Forensische Analyse eines möglicherweise kompromittierten Android-Geräts

Um die vorgehensweise zu zeigen, habe ich meine Zweifel an der Integrität meines Smartphones angezweifelt.

Mein gerootetes Google Pixel 7 („panther“) war per ADB (Android Debug Bridge) mit meinem Linux-Laptop verbunden.

Ziel war die Untersuchung potenzieller Malware oder verdächtiger Netzwerkkommunikation.

Die initiale Eingabe lautete:

Kannst du bitte eine forensische Analyse dieses Smartphones durchführen und untersuchen, ob ungewöhnliche Aktivitäten stattfinden oder stattgefunden haben?

Das sehe ich gerade in meinem Terminal:

root@michael:~ # adb shell
panther:/ $ su -
panther:/ # ^D
panther:/ $ ^D
root@michael:~ #

Phase 1: Automatisierte Aufklärung

Unmittelbar nach der Eingabe begann die KI mit eigenständiger Informationsbeschaffung gemäß der Regel „Suchen statt Fragen“.

Ein zentraler Bestandteil war das Erstellen eines lokalen Beweisverzeichnisses auf meinem Linux-Host.

# A. NETZWERK: Wer telefoniert nach Hause?
adb shell "su -c 'netstat -np | grep -v unix'" > "$LOG_DIR/network_connections.txt"

# B. PROZESSE: Was läuft?
adb shell "su -c 'ps -A -o USER,PID,PPID,NAME'" > "$LOG_DIR/process_list.txt"

# C. DROP-ZONES: Prüfung von /data/local/tmp
adb shell "su -c 'ls -laR /data/local/tmp/'" > "$LOG_DIR/temp_files.txt"

Die Analyse erfolgte vollständig datengetrieben anhand der Shell-Ausgaben.

Phase 2: Die Anomalie in `/data/local/tmp`

Die Analyse von /data/local/tmp – einer bekannten Drop-Zone für Android-Malware – offenbarte mehrere Auffälligkeiten.

Gefunden wurden unter anderem:

ein Verzeichnis namens sys-ca-copy,
eine Datei CustomCACert.log,
sowie dndsync_mobile.apk.

Insbesondere CustomCACert.log deutete auf einen möglichen Man-in-the-Middle-Angriff (MITM) hin.

Daraufhin wurde folgender Prüf-Befehl generiert:

adb shell "su -c 'mount | grep -E \"cacerts|tmp\"'"

Die Ausgabe bestätigte den Verdacht:

tmpfs on /system/etc/security/cacerts type tmpfs

Der Zertifikatsspeicher des Systems war temporär überlagert worden.

Später stellte sich heraus, dass es sich lediglich um Überreste früherer Tests meinerseits handelte, als ich den Datenverkehr von Banking-Apps untersuchte. Diese Manipulation war daher erklärbar.

Phase 3: Berechtigungen und Beweissicherung

Das Sicherheitsprotokoll bewährte sich insbesondere während der Extraktion verdächtiger Dateien.

dndsync_mobile.apk wurde als potenziell verdächtig markiert. Ein direkter adb pull schlug fehl, da die Datei Root-Rechte besaß, während ADB lediglich als Shell-User arbeitet.

Die KI analysierte das Problem korrekt und erzeugte eine sichere mehrstufige Lösung:

Datei unter neuem Namen kopieren
Berechtigungen temporär anpassen
Datei extrahieren
Temporäre Artefakte entfernen

read -p "ACHTUNG: Ich werde eine lesbare Kopie der verdächtigen APK erstellen. Fortfahren? (j/n)
" -n 1 -r

if [[ $REPLY =~ ^[Yy]$ ]]; then
    adb shell "su -c 'cp /data/local/tmp/dndsync_mobile.apk /data/local/tmp/evidence_copy.apk'"
    adb shell "su -c 'chmod 666 /data/local/tmp/evidence_copy.apk'"
    adb pull "/data/local/tmp/evidence_copy.apk" "$EVIDENCE_DIR/dndsync_mobile_suspect.apk"
    # cleanup
fi

Die KI berücksichtigte dabei automatisch Linux-Dateiberechtigungen und die Besonderheiten der Android-ADB-Architektur.

Phase 4: Statische Analyse und Kontextualisierung

Nach der Extraktion wechselte die KI zur statischen Analyse mittels Werkzeugen wie strings, unzip und file.

Dabei stellte sich heraus:

dndsync_mobile.apk war keine Malware, sondern ein legitimes Open-Source-Werkzeug zur Synchronisation von Benachrichtigungen zwischen Android und Linux.

Die SSL-Inspection blieb zwar technisch aktiv, war jedoch von mir selbst auch so gewünscht.

Diese Unterscheidung ist wichtig:

Ein System kann technisch kompromittiert erscheinen, ohne tatsächlich bösartig manipuliert worden zu sein.

Die Universalität des Prompts

Der Ansatz ist nicht auf Android oder Bash beschränkt.

Die zugrunde liegenden Prinzipien:

Zuerst analysieren
Interaktive Sicherheitsfragen einbauen
Suchen statt fragen

lassen sich auf nahezu jede Kommandozeilenumgebung übertragen.

Beispiele:

PowerShell: Der Prompt würde folgende Ausgabe erzeugen Get-Service | Where-Object Status -eq 'Stopped' anstelle zu fragen: "Welche Dienste sind gerade gestoppt?"
FortiGate: Die KI würde selbst den Befehl diagnose sys session list ausgeben und das Ergebnis prüfen, bevor Regeländerungen ausgegeben werden.

Der Prompt schließt damit die Lücke zwischen dem theoretischen Wissen eines LLMs und der praktischen Realität produktiver Systeme.

Fazit

Durch strukturierte System-Prompts wird ein LLM von einer passiven Wissensdatenbank zu einem aktiven operativen Werkzeug. So lassen sich auch ohne komplizierte Agenten, wie n8n, vergleichbare Ergebnisse erzielen.

Der Mensch fungiert dabei primär als Kontrollinstanz zwischen KI und Zielsystem.

Die Kombination aus:

„Suchen statt Fragen“
iterativer Analyse
und verpflichtenden Sicherheitsabfragen

reduziert das Risiko fehlerhafter KI-Aktionen erheblich und ermöglicht gleichzeitig eine deutlich effizientere Systemanalyse und Administration, ohne dass man seine Verwandtschaft anrufen muss 😇.