Die Zeile am Ende zeigte
Get-Content 'C:\Users\...\SSH-Tunnel unnel.log' -Tail 20
statt \tunnel.log. Aus dem Backslash-t ist beim Erzeugen der Datei ein echter
Tabulator geworden -- und der Pfad, den man kopieren soll, fuehrt damit ins
Leere.
Das ist heute Nacht die dritte Ersetzung, die an einer Escape-Ebene
gescheitert ist (nach dem \n im Compose und dem \n des Angreifers, an dem sein
eigener Schadcode zerbrach). Deshalb steht dort jetzt Join-Path statt eines
zusammengesetzten Textes: wo kein Backslash im Text steht, kann auch keiner
umgedeutet werden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der S4U-Weg aus dem letzten Commit war richtig gedacht und praktisch unbrauchbar:
das Eintragen einer S4U-Aufgabe braucht erhoehte Rechte, und in einem
gewoehnlichen PowerShell-Fenster scheitert es mit "Zugriff verweigert". Ein
Werkzeug, das Administratorrechte verlangt, benutzt am Ende niemand -- und
genau darum ging es ja: was umstaendlich ist, wird umgangen.
Jetzt startet die Aufgabe wscript.exe mit einem winzigen VBS, und dessen
Run-Aufruf hat den Fenstermodus 0. Das heisst wirklich unsichtbar, im
Unterschied zu "-WindowStyle Hidden", das bei Konsolenprogrammen in einer
interaktiven Sitzung nur halb wirkt. Besondere Rechte braucht es nicht, weil
nichts Besonderes passiert.
Der Anmeldetyp bleibt damit Interactive; das Fenster verhindert der Starter und
nicht der Anmeldetyp.
Das Protokoll aus dem letzten Commit bleibt und wird jetzt erst recht gebraucht:
sichtbar ist nichts mehr, also muss nachlesbar sein, was ssh sagt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gemeldet: "durch dein ssh script habe ich trotzdem ein powershell fenster
offen, gemerkt habe ich das weil ich es gerade geschlossen habe und die
verbindung weg war."
Genau so ist es. -LogonType Interactive laesst die Aufgabe IN der
Anmeldesitzung laufen; ein Konsolenprogramm bekommt dort ein Fenster, und
"-WindowStyle Hidden" haelt es nur halb zurueck. Wer es zumacht, kappt den
Tunnel, ohne zu wissen was er tut -- und das ist keine Randerscheinung, sondern
passiert genau einmal und dann jedes Mal wieder.
S4U ("Service for User") laeuft AUSSERHALB der Sitzung: es gibt gar keinen
Bildschirm, auf dem etwas erscheinen koennte. Auf lokale Dateien darf es
weiterhin zugreifen, und mehr braucht der Schluessel unter %USERPROFILE% nicht.
Ein Passwort muss dafuer nirgends gespeichert werden.
DAZU GEHOERT EIN PROTOKOLL, sonst tauscht man ein stoerendes Fenster gegen eine
stille Fehlfunktion: ohne Sitzung sieht niemand mehr, was ssh sagt. Ein
abgelehnter Schluessel oder ein besetzter Port waere unsichtbar -- der Tunnel
stuende einfach nicht, und niemand wuesste warum. tunnel.log haelt jeden
Verbindungsversuch fest und wird bei 1 MB verworfen.
Das Skript sagt am Ende auch, wie man ohne Fenster nachsieht:
Get-NetTCPConnection -LocalPort 13389 -State Listen, und die letzten Zeilen des
Protokolls.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Standard fuer -Benutzer war $env:USERNAME -- der Name am HEIMRECHNER. Auf
dem Server heisst das Konto anders (hier "az319" gegen "Darkster"). Das Skript
lief sauber durch, trug die Aufgabe ein, und der Tunnel kam trotzdem nicht.
SCHLIMMER ALS DER FEHLER WAR DIE DIAGNOSE. Am Ende stand fest verdrahtet
"Haeufigste Ursache: der oeffentliche Schluessel ist noch nicht hinterlegt" --
eine GERATENE Ursache, und sie war falsch. Wer dem folgt, prueft den Schluessel,
findet ihn in Ordnung und sucht weiter an der falschen Stelle.
Jetzt wird gemessen: schlaegt der Tunnel fehl, baut das Skript selbst eine
SSH-Verbindung auf und wertet aus, was der Server antwortet -- "Permission
denied" (dann Name ODER Schluessel, beides benannt), nicht erreichbar,
Weiterleitung verweigert, oder ssh kommt durch und es liegt am Ziel-Port.
Und -Benutzer hat keinen Standard mehr. Fehlt er, wird gefragt: "Wie heisst
dein Konto AUF DEM SERVER? (nicht der Name hier am PC)". Einmal fragen ist
besser als einmal in die Irre fuehren.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
LAEUFT AUF DEM HEIMRECHNER, nicht auf dem Server.
Seit dem 13.08.2026 ist RDP am Server gesperrt; hinein geht es nur noch durch
einen SSH-Tunnel mit Schluessel. Von Hand hiesse das: vor jeder Sitzung ein
PowerShell-Fenster oeffnen, einen Befehl tippen, das Fenster offen lassen.
DAS HAELT NIEMAND DURCH, UND WAS NIEMAND DURCHHAELT, WIRD UMGANGEN -- am Ende
steht dann wieder ein offener Port. Das Skript macht den Tunnel deshalb zu
etwas, das man nicht sieht: eine Aufgabe, die beim Anmelden startet, sich bei
Abbruch selbst neu aufbaut und kein Fenster zeigt. Danach verbindet man sich
wie immer, nur auf localhost statt auf die Server-Adresse.
Drei Sachen, die es prueft statt sie anzunehmen:
- Ist ein SSH-Client da? Sonst der Nachinstallationsbefehl statt eines
kryptischen Fehlers.
- Gibt es einen Schluessel? Sonst anlegen UND den oeffentlichen Teil gross
ausgeben, damit klar ist, was zu schicken ist.
- Ist der lokale Port frei? Das ist der Fehler, der uns heute Nacht eine
halbe Stunde gekostet hat: 3389 ist unter Windows selbst belegt, die
Verbindung landet dann auf dem EIGENEN PC, und die Meldung lautet
"Konsolensitzung bereits aktiv" -- man sucht den Fehler ueberall, nur
nicht beim Port. Standard ist deshalb 13389.
Die Schleife um ssh ist Absicht: bei Zwangstrennung, Standby oder kurzem
Aussetzer endet ssh, und ohne Schleife waere der Tunnel weg, ohne dass es
jemand merkt -- bis die naechste Verbindung scheitert.
ExitOnForwardFailure=yes gehoert dazu, sonst laeuft ssh scheinbar, waehrend die
Weiterleitung gar nicht steht.
Gedacht auch fuer Mitbenutzer, die sich mit Rechnern nicht auskennen: einmal
ausfuehren, oeffentlichen Schluessel schicken, fertig. Danach sehen sie vom
Tunnel nie wieder etwas.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
D4rkst3randClaude Opus 5