Hallo!
Gesetzt, daß
ssh irgendeinaccount@irgendeinhost
funktioniert, ist mein Verständnis einer Zeile wie
ssh -L 8888:irgendeinhost:9999 irgendeinaccount@irgendeinhost
dieses, daß ssh Anfragen auf (lokaler Host, Interface lo) Port 8888 entgegennimmt, zum sshd auf der anderen Seite über Port 22 tunnelt , und der wiederum das Ganze dort auf (irgendeinhost, Interface lo) Port 9999 ausgibt.
Auf irgendeinhost kann ich dann: 1.) so etwas wie netcat -p 9999 -l machen, um auf Userebene zu sehen, was ankommt, oder 2.) ebenso die Pakete per tcpdump -nt -i lo beobachten.
Das klappt "meistens". In diesem bestimmten Fall aber leider nicht.
Die Verbindung wird aufgebaut, ein richtiges Tunneln erfolgt nicht, Pakete sind am lo-Interface von irgendeinhost nicht sichtbar.
Kennt jemand eine Debug-Möglichkeit? Eine Erklärung? Oder sogar die Lösung?
(Vielleicht Ist dem sshd per Konfig-Option keine Benutzung des lo-Interfaces möglich? Ach so: Völlig lokal auf irgendeinhost klappt es wie gewollt. sshd "lauscht" auch an allen Interfaces. Iptables sind nicht im Spiel. Ich glaube auch nicht, daß auf Providerseite ein "ssh-Proxy" (a la "man in the middle") Portforwarding filtert.)
Ratlos ....
Bernhard
Bernhard Schiffner bernhard@schiffner-limbach.de schrieb:
ssh -L 8888:irgendeinhost:9999 irgendeinaccount@irgendeinhost
dieses, daß ssh Anfragen auf (lokaler Host, Interface lo) Port 8888 entgegennimmt, zum sshd auf der anderen Seite über Port 22 tunnelt , und der wiederum das Ganze dort auf (irgendeinhost, Interface lo) Port 9999 ausgibt.
Warum Interface "lo" auf dem anderen Host? Sollte es nicht ethX sein? Du kannst mit dem Format anderen Hosts ansprechen, und ich denke, es sollte automatisch nach Route gewählt werden (vom "irgendeinhost") welche Schnittstelle benutzt werden soll. Wird die gleiche Adresse gegeben, wird aber auch nicht unbedingt "lo" benutzt, denn sie ist nur für 127.0.0.1 zu nutzen. Sogar wenn der Host 192.168.1.1 mit sich selber (auch 192.168.1.1) sprechen soll wird das, meiner Wissen nach, über ethX (vermutlich eth0) passieren.
Grüße Luca Bertoncello (lucabert@lucabert.de)
Am Dienstag, 22. Juni 2010, 21:46:03 schrieb Luca Bertoncello:
Bernhard Schiffner bernhard@schiffner-limbach.de schrieb:
ssh -L 8888:irgendeinhost:9999 irgendeinaccount@irgendeinhost
dieses, daß ssh Anfragen auf (lokaler Host, Interface lo) Port 8888 entgegennimmt, zum sshd auf der anderen Seite über Port 22 tunnelt , und der wiederum das Ganze dort auf (irgendeinhost, Interface lo) Port 9999 ausgibt.
Warum Interface "lo" auf dem anderen Host? Sollte es nicht ethX sein?
Achtung 2 Welten!
1.) sshd lauscht (wenn nicht anders konfiguriert) an allen Interfaces Port 22.
2.) Wenn sshd Portforwarding übernimmt, reicht er die an (irgendeinem Interface) Port 22 empfangenen und entschlüsselten Pakete an Interface 127.0.0.1:Port (bei mir lo:9999) weiter. Dort können dann wieder andere Dienste lauschen.
(man sshd_config -> GatewayPorts)
Du kannst mit dem Format anderen Hosts ansprechen, und ich denke, es sollte automatisch nach Route gewählt werden (vom "irgendeinhost") welche Schnittstelle benutzt werden soll. Wird die gleiche Adresse gegeben, wird aber auch nicht unbedingt "lo" benutzt, denn sie ist nur für 127.0.0.1 zu nutzen.
Eben. lo alias 127.0.0.1 ist für die Fälle gedacht, wo der Host mit sich selber über Netzwerk sprechen will (z.B. wg. Trennung bzw. Stacking der Applikationen, Portforwarding)
Sogar wenn der Host 192.168.1.1 mit sich selber (auch 192.168.1.1) sprechen soll wird das, meiner Wissen nach, über ethX (vermutlich eth0) passieren.
Teste das mal mit tcpdump. Eine Verbindung von mir an mich via extern sichtbarer Schnittstelle (wie ethX alias 192.168.1.1) ist keinesfalls verboten. (Trotzdem halte ich es für "nicht wünschenswert", das zuzulassen. Wenn ich Netze betreuen muß, fange ich so etwas mit iptables-Regeln ab.)
Grüße Luca Bertoncello (lucabert@lucabert.de)
Danke!
Bernhard
Hallo Bernhard,
On Wed, Jun 23, 2010 at 09:33:36 +0200, Bernhard Schiffner wrote:
1.) sshd lauscht (wenn nicht anders konfiguriert) an allen Interfaces Port 22.
Klar.
2.) Wenn sshd Portforwarding uebernimmt, reicht er die an (irgendeinem Interface) Port 22 empfangenen und entschluesselten Pakete an Interface 127.0.0.1:Port (bei mir lo:9999) weiter. Dort koennen dann wieder andere Dienste lauschen.
Das Forwarding muss aber nicht zwingend nach 127.0.0.1 gehen, es kann auf eine beliebige vom sshd aus erreichbare, nicht lokale IP-Adresse gehen. In dem Fall werden die Pakete vom sshd nicht auf lo gesendet, sondern auf das Interface, ueber das die Route zu dieser IP-Adresse laeuft. (ip route get <IP-Adresse>)
Sogar wenn der Host 192.168.1.1 mit sich selber (auch 192.168.1.1) sprechen soll wird das, meiner Wissen nach, ueber ethX (vermutlich eth0) passieren.
Hier liegt Luca falsch. Sobald ein Paket an eine lokal erreichbare IP-Adresse geht (sprich: irgendein Interface hat diese Adresse), wird der Traffic ueber lo gesendet. Deswegen ist es z.B. auch unsinnig, sich selbst mit nmap zu scannen, um Firewallregeln fuer externen Traffic zu testen.
Gruss, Chris
Bernhard Schiffner bernhard@schiffner-limbach.de (Di 22 Jun 2010 20:48:22 CEST):
Hallo!
Gesetzt, daß
ssh irgendeinaccount@irgendeinhost
funktioniert, ist mein Verständnis einer Zeile wie
ssh -L 8888:irgendeinhost:9999 irgendeinaccount@irgendeinhost
dieses, daß ssh Anfragen auf (lokaler Host, Interface lo) Port 8888 entgegennimmt, zum sshd auf der anderen Seite über Port 22 tunnelt , und der wiederum das Ganze dort auf (irgendeinhost, Interface lo) Port 9999 ausgibt.
Auf irgendeinhost kann ich dann: 1.) so etwas wie netcat -p 9999 -l machen, um auf Userebene zu sehen, was ankommt, oder 2.) ebenso die Pakete per tcpdump -nt -i lo beobachten.
Das klappt "meistens". In diesem bestimmten Fall aber leider nicht.
-L local_port:remote_host:remote_port
… damit wird deine lokale Verbindung zu local_port zu remote_host:remote_port ist in *Bezug auf das Zielsystem* weitergereicht. Ob ueber lo oder irgendwas anderes, kann man nicht vorher sagen.
Die Verbindung wird aufgebaut, ein richtiges Tunneln erfolgt nicht, Pakete sind am lo-Interface von irgendeinhost nicht sichtbar.
Bei "-v" siehst Du den Tunnel-Aufbau, wenn er erfolgt, moeglicherweise auch eine Ausrede, wenn es nicht funktioniert.
Lokale Ports <1024 gehen nur, wenn Du root bist.
Hallo,
ich lese gerade VServer… ist der Client oder der Server ein VServer? Denn ich glaube mich zu entsinnen, dass da einige Netzwerkdinge nicht so gingen, wie man es sich gemeinhin vorstellt.
Am Dienstag, 22. Juni 2010, 22:38:10 schrieb Heiko Schlittermann:
Hallo,
ich lese gerade VServer… ist der Client oder der Server ein VServer? Denn ich glaube mich zu entsinnen, dass da einige Netzwerkdinge nicht so gingen, wie man es sich gemeinhin vorstellt.
Hier: eine (OpenSuse-) Linux-Kiste mit vollem root-Zugriff.
Dort: scheinbar ein Windows-Virtualisierer mit einem SLES11 als Gast, das ich in dem Fall benutze (root innerhalb des SLES11).
Scheinbar sind da noch Firewalls o.ä. dazwischen, das habe ich aber nicht unter Kontrolle. Ich bin der Meinung, wenn ssh geht, sollte auch Portforwarding gehen.
Bernhard
Bernhard Schiffner bernhard@schiffner-limbach.de (Mi 23 Jun 2010 09:33:56 CEST):
Am Dienstag, 22. Juni 2010, 22:38:10 schrieb Heiko Schlittermann:
Hallo,
ich lese gerade VServer… ist der Client oder der Server ein VServer? Denn ich glaube mich zu entsinnen, dass da einige Netzwerkdinge nicht so gingen, wie man es sich gemeinhin vorstellt.
Hier: eine (OpenSuse-) Linux-Kiste mit vollem root-Zugriff.
Dort: scheinbar ein Windows-Virtualisierer mit einem SLES11 als Gast, das ich in dem Fall benutze (root innerhalb des SLES11).
Scheinbar sind da noch Firewalls o.ä. dazwischen, das habe ich aber nicht unter Kontrolle. Ich bin der Meinung, wenn ssh geht, sollte auch Portforwarding gehen.
Ja. Wäre auch meine Meinung.
Am Dienstag, 22. Juni 2010, 20:48:22 schrieb Bernhard Schiffner:
Hallo!
Gesetzt, daß
ssh irgendeinaccount@irgendeinhost
funktioniert, ist mein Verständnis einer Zeile wie
ssh -L 8888:irgendeinhost:9999 irgendeinaccount@irgendeinhost
...
Kennt jemand eine Debug-Möglichkeit? Eine Erklärung? Oder sogar die Lösung?
Debug: lsof -i -nP | grep sshd
Sorgfältiges (!) Lesen bringt irgendwann die Erleuchtung: im konkreten (virtualisierten) Fall muß es
ssh -L 8888:localhost:9999 irgendeinaccount@irgendeinhost
heißen. Danke für alle Tips!
Bernhard
Erklärung: irgendeinhost hat eine offizielle IP, die dann ihrerseits ssh, hhtp etc. an eine private IP dort im Netz (eben den VServer) übermittelt. Wenn dann der sshd versucht die Pakete an die offizielle IP weiterzuleiten, kann ich sie lokal nicht mehr "benutzen", und auf dem Gateway mit der offiziellen IP gehen sie sehr wahrscheinlich zu -j DROP.
lug-dd@mailman.schlittermann.de
-
Bernhard Schiffner -
Christian Perle -
Heiko Schlittermann -
Luca Bertoncello