Peters Spickzettel SSH-Tunnel, 7.10.2006, 15.11.2006. Fall A (Zugriff auf Service auf Rechner hinter Firewall): Die Rechner "intern" und "public" gehoeren beide zum gleichen Firmen-Netzwerk, "intern" ist von aussen nicht erreichbar, wohl aber von "public" aus. Jemand moechte von einem externen Rechner "extern" aus auf einen auf Port 80 laufenden Webserver (z. B. ein internes Wiki) auf "intern" zugreifen. Loesung: extern> ssh -2 -N -f -l publicuser -L9999:intern:80 public Nun kann ich auf "extern" den Webserver auf "intern" durch Eingabe des folgenden Urls erreichen: http://localhost:9999 Natuerlich muss publicuser auf "public" existieren, sein Kennwort wird abgefragt. ----------------------------------------------- Fall B (Zugriff auf Rechner hinter Firewall): Es soll von "irgendwo" per ssh auf einen Rechner "intern" zugegriffen werden, der hinter einer Firewall steht. Hierzu muss von "intern" aus ein Tunnel zu einem oeffentlich erreichbaren Rechner "public" gegraben werden. Loesung: intern> ssh -g -R 50022:localhost:22 publicuser@public # graebt den Tunnel jetzt von "irgendwo" per ssh auf public einloggen (ssh publicuser@public) und dann von dort aus: public> ssh -g -p 50022 internuser@localhost natuerlich muss auf "public" ein user "publicuser" existieren und auf "intern" ein user "internuser", die entsprechenden Kennworte werden jeweils abgefragt. Auf "intern" muss ein ssh-Daemon laufen. ... und da hab ich's her (Fall A): aus einem Forenbeitrag von dzi Dieter (http://www.bsdforen.de/showthread.php?t=911) -------- ssh tunnel aufbauen [4newbies as well] 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... --------- ... und da hab ich's her (Fall B): http://www.pro-linux.de/news/2002/4826.html Man kennt das. Ausgerechnet der Arbeitsrechner, auf dem genau die Daten sind, an die man unbedingt gelangen wollte, steht hinter einer Firewall, die keine ankommenden Verbindungen ins lokale Netz erlaubt. Doch diesem Problem kann man mit einem ssh-Tunnel vorbeugen, indem man das "Remote Port Forwarding" aktiviert, was seit geraumer Zeit zu ssh gehört. Doch zuerst sollte man ein paar Vorbereitungen treffen. Auf dem Arbeitsrechner hinter der Firewall (A genannt) richtet man wie gewohnt den sshd so ein, daß er an Port 22 horcht und Verbindungen von Überall akzeptiert. In der sshd_config sollten also folgende Dinge stehen: Port 22 ListenAddress 0.0.0.0 (Man kann später immer noch den Zugriff beschränken, aber erstmal alles zulassen.) Damit das Forwarding auf der Server-Seite auch funktioniert, ist es bei älteren ssh-Version notwendig, den Parameter "GatewayPorts Yes" in die sshd_config einzufügen. Damit wird entfernten Rechnern erlaubt, sich mit einem Forwarding einzuloggen. Nachdem man den ssh-Daemon gestartet hat, verbindet man sich von A auf einen Rechner vor der Firewall (genannt B), der von überall aus dem Internet erreichbar ist: ssh -g -R 50022:localhost:22 login@B Die Option "-g" erlaubt entfernten Rechnern (wie B) die Verbindung auf lokale weitergeleitete Ports (also 'geforwardete' Ports auf A). Die Option "-R" gefolgt von dem Einwahl-Port 50022 des Rechners B, dem Rechner B bekannten Adresse (localhost) und dem Zielport 22 von A (an dem sshd horcht), bewirkt die eigentliche Weiterleitung. Das funktioniert so: Auf Rechner B horcht die bestehende ssh-Verbindung an Port 50022 unter localhost. Falls sich jemand via "ssh -g -p 50022 login@B" dort einloggt, wird die Verbindung 'rückwärts' zu A durch die Firewall geleitet an Port 22. (login ist ein Loginname des Rechners A.) Aber nochmal kurz und verständlich: Von A (dem lokalen Rechner) aus (hinter der Firewall): ssh -g -R remote_port:localhost:local_port login@B Von irgendwo vor der Firewall auf B einloggen: ssh login@B ssh -g login@localhost Und man landet auf dem Rechner hinter der Firewall. Man kann so übrigens auch auf andere Dienste hinter einer Firewall zugreifen. Leitet man z.B. den Port 50080 zu Port 80 weiter, so kann man einen Webserver auch hinter einer Firewall ansprechen.