Natürlich ist es auch möglich, ein Portforwarding auf einen Host im Netz einzurichten, um diesen erreichbar zu machen, in diesem Fall ist aber der RDP-Port für Jedermann erreichbar und im schlimmsten Fall der Traffic zum Client unverschlüsselt. Es sind bereits Sicherheitslücken entdeckt worden, selbst Microsoft empfiehlt, RDP-Verbindungen mittels Transport Layer Security (TLS) zusätzlich abzusichern. siehe dazu [4]. Wer dies also tun möchte, sollte sich jedoch mindestens der jeweiligen Sicherheits - bzw. Verschlüsselungseinstellungen seines RemoteDesktopServers bewusst sein. siehe hierzu: [1] und [2]

In diesem Howto geht es aber um die Erzeugung eines verschlüsselten Tunnels mittels SSH, um einen beliebigen Rechner hinter dem Fli zu erreichen, der RDP-Port ist nicht exposiert und es sind beliebig viele Rechner hinter dem Fli erreichbar, ohne irgendwelche Portforwardings einzurichten.

Der Client (Windows XP) ist irgendwo im Internet und baut eine Verbindung zur bekanntgemachten IP des Fli4l auf (Hierfür ist z.B OPT_DYNDNS oder ähnliches brauchbar). dieser bietet SSH an und hat /usr/local/bin/wol installiert. Hinter dem Fli ist die Zielmaschine 192.168.1.90 (Windows XP mit freigegebenem Remotedesktop) in ausgeschaltetem Zustand.

Aus der Ferne den Zielrechner einschalten und mit dem Remotedesktop über einen SSH-Tunnel verbinden.

Es ist möglich, beliebige Ports vom Clientrechner über die SSH-Verbindung an einen Beliebigen Rechner im Zielnetz weiterzuleiten. Der Vorteil dieser Variante ist, dass der Port für die Remotedesktopverbindung nicht im Internet freigegeben ist und ich eventuell auch zu verschiedenen Rechnern im Zielnetz Verbindungen aufbauen kann. Dies geschieht per Kommandozeilenoption mit plink.exe. Eine Remotedesktopverbindung benötigt einzig und allein den Port 3389. Es gibt nur ein Problem: wenn der Client die Remotedesktopverbindung mit dem Tunnel aufbauen will, meckert das Windowstool für den Remotedesktop, dass es pauschal keine Verbindung mit dem Lokalen Rechner aufbauen mag ( wo ja das client-ende des Tunnels endet). Da aber in neueren Versionen von plink.exe auch ports auf anderen IPs als 127.0.0.1 umgeleitet werden können, tun wir einfach so, als gebe es einen Rechner mit der IP 127.0.0.2. Die zugehörige Kommandozeilenoption lautet:

-L 127.0.0.2:3389:192.168.1.90:3389

(Zielmaschine 192.168.1.90 mit freigegebenem Remotedesktop)

Jetzt mag auch das Windows-Tool für den Remotedesktop mit dem Tunnel verbinden. Es ist fast alles fertig. Der komplette String könnte so aussehen(Achtung, alles auf einer Zeile!):

plink.exe -ssh -2 -v -L 127.0.0.2:3389:192.168.1.90:3389
-l fli4l -pw meinPasswort meinFl4lmitssh.dyndns.org

Jetzt könnte der Remotedesktop der Zielmaschine bereits angesprochen werden, indem wir die Remotedesktopverbindung wie folgt starten:

mstsc /v:127.0.0.2 /f
									

Wenn der Zielrechner bereits an ist, kann man jezt den Client für die Remotedesktopverbindung starten und die IP 127.0.0.2 eingeben. Dies sollte zu einem erfolgreichen Verbindungsaufbau mit dem Zielrechner führen. Da ich aber gesagt hatte, ich möchte den Rechner auch aus der Ferne anschalten, benutze ich die Möglichkeit, plink.exe einige Befehle für den Fli mitzugeben, damit dieser den Zielrechner aufwecken kann. Diese lauten: (Achtung, alles auf einer Zeile!)

if /usr/local/bin/wol 00:E0:18:BF:B3:36; then echo wol an Ziel gesendet; 
fi; sleep 120;								

Ja, es ist möglich auch mehrere Befehle nacheinander an den Fli4l zu geben. theoretisch ganze Skripte... das Tool für wake-on-lan muss natürlich auf dem fli4l installiert sein es benötigt die MAC-Addresse des Zielrechners. Das sleep 120 wartet 120 Sekunden. wenn in dieser Zeit kein Tunnel aufgebaut wird, beendet sich die SSH-Session von selbst. Jetzt also endlich der gesamte Ausdruck: (Achtung, alles auf einer Zeile!)

plink.exe -ssh -2 -v -L 127.0.0.2:3389:192.168.1.90:3389
-l fli4l -pw meinPasswort meinFl4lmitssh.dyndns.org
if /usr/local/bin/wol 00:E0:18:BF:B3:36;
then echo wol an Ziel gesendet; fi; sleep 120;
									

Bei XP SP2 kann man nur noch auf 127.0.0.1 als Loopbackdevice zugreifen. Dies ist ein Fehler, der mit dem Windows-Patch (KB884020) behoben wurde. Aktuelle Rechner sollten also mit dem bisherigen Skript wunderbar funktionieren.
Da es aber unterwegs leider leicht vorkommen kann, dass man an einem "veralteten SP2" sitzt, hier eine leicht abgeänderte Version, die 127.0.0.1, jedoch mit anderem Port benutzt:

plink.exe -ssh -2 -v -L 127.0.0.1:3388:192.168.1.90:3389
-l fli4l -pw meinPasswort meinFl4lmitssh.dyndns.org
if /usr/local/bin/wol 00:E0:18:BF:B3:36;
then echo wol an Ziel gesendet; sleep 120; fi;				

Jetzt muß der Ausdruck für die Remotedesktopverbindung natürlich den Port enthalten:

mstsc /v:127.0.0.1:3388 /f 
									

Wer in einem Firmennetzwerk gelegentlich "nach Hause telefonieren" möchte, sollte dies natürlich mit dem Sicherheitsverantwortlichen besprochen haben. Da Firmennetze ihre Mitarbeiter oft über proxys ins Internet lassen, ist ein Zugriff mit plink nicht möglich, da dieses Proxys nicht unterstützt. Desweiteren sind proxys meist sehr restriktiv konfiguriert und erlauben nur Traffic auf Port 80 und Port 443 (ssl).

Der Trick ist, den SSHd auf Port 443 zu starten. Proxys wie Squid können nicht zwischen SSL und SSH unterschenden. In diesem Fall kann man putty leicht die Benutzung von Proxys beibringen, der Squid denkt, es wäre SSL und alles sollte funktionieren. Zu Putty ist nur zu sagen, dass man unter dem Menüpunkt Tunnels Die Variable "Source port" auch mit einem Längeren String wie z.B:127.0.0.1:3388 setzen kann, auch wenn das Eingabefeld so klein ist. Bitte unbedingt die jeweils aktuellste Version von putty herunterladen, da nicht alle benötigten Features schon immer bei putty vorhanden waren.

rdesktop ist Dein Freund. Hier sind allerdings nicht alle Versionen uneingeschränkt für die hohe Verschlüsselung geeignet. Je nach Konfiguration des RemoteDesktopServers kann es passieren, dass eine relativ unsichere Verbindung ausgehandelt wird. speziell in diesem Fall ist der SSH-Tunnel ebenfalls sehr willkommen. Trick: unbedingt die Option -a 16 oder -a 24 benutzen, um die vollen Farben für die Verbindung zu aktivieren. rdesktop macht einen sehr guten Eindruck, ich hatte allerdings teilweise Probleme mit der Keymap, einige (wichtige) sonderzeichen und Umlaute gingen nicht auf Anhieb.

Für Windows 95, Windows 98 und 98 Second Edition, Windows Me, Windows NT 4.0, und Windows 2000. gibt es einen kostenlosen RDP Client von Microsoft (siehe [3]), bei XP ist er (wie auch der Server) dabei. Da dieser Client mstsc.exe zusammen mit der mstlsapi.dll auch auf Windows-XP laeuft, kann man die beiden Dateien auch einfach aus einem vorhandenen Windows-XP system nehmen, auf einen USB-Stick speichern und grundsätzlich von hier starten. Es geht auf allen Systemen.

Geht man von einem Fli an einem DSL-Anschluss mit 768KBit aus, so reicht ein älterer Rechner aus um den zusätzlichen Verschlüsselungsaufwand zu bewältigen. Hier ist das Nadelöhr auf jeden Fall der geringe Upload. Es funktioniert allerdings erstaunlich gut. Was den Traffic betrifft, sollte so gut wie kein Overhead entstehen, da der Chiffretext genauso gross ist wie der Klartext.

Man kann bestens sehen, ob der Tunnel funktioniert:

C:\Programme\putty>plink.exe -ssh -2 -v -L 127.0.0.1:3388:192.168.1.90:33
89 -l fli4l -pw meinPasswort meinFli4lmitssh.dyndns.org if /usr/local/bin/wol 00:E0:18:BF
:B3:36;then echo wol an Zielhost gesendet; sleep 120; fi;
Server version: SSH-2.0-OpenSSH_3.6.1p2
We claim version: SSH-2.0-PuTTY_Release_0.58
Using SSH protocol version 2
Doing Diffie-Hellman group exchange
Doing Diffie-Hellman key exchange
Host key fingerprint is:
ssh-rsa 1024 bf:95:12:61:d1:87:9a:a3:bc:ba:b6:ef:da:9a:be:20
Initialised AES-256 client->server encryption
Initialised HMAC-SHA1 client->server MAC algorithm
Initialised AES-256 server->client encryption
Initialised HMAC-SHA1 server->client MAC algorithm
Using username "fli4l".
Keyboard-interactive authentication refused
Sent password
Access granted
Opened channel for session
Local port 127.0.0.1:3388 forwarding to 192.168.1.90:3389
Started a shell/command
wol an Zielhost gesendet
									

Wenn man so weit ist, kann man versuchen

mstsc /v:127.0.0.1:3388 /f
									

auszuführen, bis

									
Opening forwarded connection to 192.168.1.90:3389

in der Konsole erscheint. Dies geschieht nur, wenn der Zielhost erreichbar ist. Jetzt sollte alles funktionieren. Es kann natürlich etwas dauern, bis der Windows-Rechner gestartet ist.

Mit diesem Grundgerüst kann man natürlich noch eine Menge anfangen. Wer Nachbesserungsbedarf sieht, kann ja ein wenig herumprobieren... Ich mag es eher simpel. Man kann dies zum Beispiel zusammen mit plink.exe auf einen Usb-Stick kopieren und damit jederzeit zuhause nach dem rechten sehen. In diesem Fall kann man natürlich das Passwort (-pw meinPasswort) einfach weglassen. Es erscheint dann ein Dialog zur Eingabe im Terminalfenster. Natürlich dürfen die beiden Befehle nicht in die selbe bat-Datei, da plink blockiert bis die Session sich nach 120 Sekunden beendet. Eine möglichkeit ist, den plink-Aufruf in eine Batch-Datei zu packen und den RDP-Aufruf ebenfalls in eine eigene. Keep it simple...
Ich hoffe, Ihr habt Spass! Ich baue schon seit tagen sinnlose Verbindungen nach hause auf und freue mich tierisch über den neugewonnenen Luxus :) Es ist übrigens auch möglich, in dem Remotedesktop-tool ein Laufwerksmapping vom clientrechner an den Zielrechner einzurichten. so steht dann auch einem Dateiaustauch zwischen den beiden Rechnern nichts mehr im Wege.

[1] Microsoft TechNet: Configuring Remote Desktop
[2] Microsoft TechNet: Configuring authentication and encryption
[3] Microsoft.com: Remote Desktop Connection Software Download
[4] Heise Security: Kleiner Lauschangriff gegen Windows-Fernwartung
[5] wissh -RDP over SSH Tunneling

Autor: Stefan Diercks   Datum: 20.02.2006