ssh Tunnel

Nehmen wir folgende topologie an.

Der Server "rambo" und "sam" stehen hinter einer firewall welche mit relativ strengen regeln aufgesetzt ist. Nehmen wir auch an "rambo" ist ein w2k server und kann lediglich Ýber Terminal service erreicht werden. "sam" hingegen ist ein unix/linux server und ist Ýber ssh erreichbar. Erlaubt ist die eingehende verbindung Ýber ssh zu "sam".

Die firewall erlaubt es "sam" Ýber den port 3389 (terminal services) eine Verbindung zu "rambo" aufzubauen. Aber nicht vom rest der welt.

Laut Firewall ist es nicht mÆglich "rambo" mit rdesktop (ts-client fÝr unix, sehr zu empfehlen(wenns Ähnliches benÆtigt wird)).
Wir gehen auch davon aus das unser admin (pc/laptop) ein unix oder linux installiert hat und Ýber den ssh client und rdesktop verfÝgt.

Der admin baut nun einen ssh tunnel zu "sam" auf, welcher denn port 3389 auf den localhost (admin pc) durchschleift. Sprich, der admin wird nach aufbau des tunnels eine verbindung auf diesen Port auf seinen eigenen PC aufbauen welcher aber nicht wirklich der localhost ist, sonder "rambo".

adminpc# ssh -2 -N -f -l samsuser -L3389:rambo:3389 sam

wichtig ist dass

1. samuser auf sam existiert und berechtigt per ssh verbindungen aufzubauen.

2. Der host rambo in der /etc/hosts existiert, wenn nicht die ip von rambo genutzt wurde.

3. in diesen Fall Protocol 2 von sshd akzepiert wird

auf die schalter gehe ich spÄter ein...

Der Admin erstellt, nach erfolgreicher authentifizierung, nun die verbindung zu "rambo" mit rdesktop auf.

adminpc# rdesktop -kde localhost

nun sollte ein 800x600 grosse fenster mit dem login von "rambo" erscheinen und schon kann admin auch mal nen reboot ohne powerpole machen

Zu beachten ist auch, dass nach beendigung der Verbindung zu "rambo" die offene ssh Verbindung zu sam weiter besteht bis diese nicht explizit gekillt wird.

thats it...

zu den schaltern des ssh client

-2 ( dÝrfte klar sein) protokol
-N es sollen keine remote commando's ausgefÝhrt werden (auf sam)

Interessant ist auch der schalter -f

Dieser verursacht dass die ssh session im untergrund lÄuft. Man sollte sich immer Ýberlegen was man wirklich tunneln will, gerade bei Xanwendung ist dieser schalter sehr sinnvoll.

-l (sollte auch klar sein) benutzer.


-L definiert den Port zum dem eine locale verbindung aufgebaut werden soll. Im falle eines bereits vom adminpc belegten port muss ein anderer wie 10001 oder Ähnliches definiert werden. Dabei muss natÝrlich bei rdesktop der schalter -t 10001 verwendet werden.


Nehmen wir einmal an "rambo" wÄre ein solaris system mit einer Java application nutzbar auf einer Xwindow umgebung. Jedoch sind von der firewall auch ssh geblockt. So dass nun wieder nur die mÆglichkeit besteht Ýber einen tunnel diese application auszufÝhren.

also ein

adminpc# ssh -2 -X -lrambouser rambo

funktioniert nicht und das X forwarding scheitert demnach auch.

deshalb muss admin einen tunnel mit sam aufbauen

adminpc# ssh -2 -N -f -lsamuser -L9999:rambo:22 sam

nun besteht ein tunnel von port 9999 auf dem localhost zu port 22 auf "rambo".

Das hat zur folge das nun eine ssh verbindung zu localhost mit X forwarding zu port 9999 aufgebaut werden muss.

adminpc# ssh -2 -X -lrambouser -p9999

die authentifizierung klappt wenn passwort und user auf rambo existieren !

rambo# pwd

/usr/home/rambouser

rambo#

rambo#/opt/java/bin/javabeispiel.sh start &

jetzt sollte die application auf dem desktop des admins erscheinen. Und der admin kann admin sein...