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