D
dzi
Guest
Zum thema ssh hab ich bereits einige Beiträge gesehen, jedoch konnte ich nichts über tunnels finden und hab mir gedacht, dass man das doch mal erklären sollte.
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...
Referrenzen:
ssh -- die manpage von ssh oder http://openssh.org
rdesktop -- http://rdesktop.org
Bei weiterem interesse schreib ich gern auch ein, praktisch advanced wenn man so will.
Ich hoffe dass mein Beitrag für euch vielleicht mal brauchbar ist. Ich jedenfalls brauch das fast jeden Tag...
Dieter
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...
Referrenzen:
ssh -- die manpage von ssh oder http://openssh.org
rdesktop -- http://rdesktop.org
Bei weiterem interesse schreib ich gern auch ein, praktisch advanced wenn man so will.
Ich hoffe dass mein Beitrag für euch vielleicht mal brauchbar ist. Ich jedenfalls brauch das fast jeden Tag...
Dieter
Zuletzt bearbeitet von einem Moderator:
roxyport -F 22 ip-meines-servers