54
Reverse SSH Tunnel mit Putty unter Windows bauen
Guten Morgen,
Ich möchte einen Tunnel wie hier https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/ bauen.
Leider funktioniert die Anleitung nicht wenn ich sie so nach mache.
Kann mir jemand sagen ob die Anleitung was taugt oder muss ich Grundlegend etwas anders machen?
Wenn das dann funktioniert möchte ich den Tunnel dann auf ein Gerät was im selben Lan wie das Gerät A ist erweitern.
Das Gerät ist eine SPS und ich muss eine änderung machen. Ich darf im Moment nicht zu diesem Gerät hin fahren.
Die Sps hört auf Port 900.
Mir steht ein Debian Server mit Fixer Ip zur Verfügung.
Danke für die Hilfe
Ich möchte einen Tunnel wie hier https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/ bauen.
Leider funktioniert die Anleitung nicht wenn ich sie so nach mache.
Kann mir jemand sagen ob die Anleitung was taugt oder muss ich Grundlegend etwas anders machen?
Wenn das dann funktioniert möchte ich den Tunnel dann auf ein Gerät was im selben Lan wie das Gerät A ist erweitern.
Das Gerät ist eine SPS und ich muss eine änderung machen. Ich darf im Moment nicht zu diesem Gerät hin fahren.
Die Sps hört auf Port 900.
Mir steht ein Debian Server mit Fixer Ip zur Verfügung.
Danke für die Hilfe
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 564726
Url: https://administrator.de/forum/reverse-ssh-tunnel-mit-putty-unter-windows-bauen-564726.html
Ausgedruckt am: 21.04.2025 um 21:04 Uhr
54 Kommentare
Neuester Kommentar
Hallo, warum keine stinknormale vpn?
Weil ich es nur ganz Temporär brauche!
Und weil mich diese Art Tunnel interessiert.
Und weil mich diese Art Tunnel interessiert.
Zitat von @SonnenTony:
Guten Morgen,
Ich möchte einen Tunnel wie hier https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/ bauen.
Leider funktioniert die Anleitung nicht wenn ich sie so nach mache.
Guten Morgen,
Ich möchte einen Tunnel wie hier https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/ bauen.
Leider funktioniert die Anleitung nicht wenn ich sie so nach mache.
Moin,
was genau funktioniert nicht?
- verbindugnsaufbau?
- Authentifikation?
- Verbinden auf den Tunnel von außen?
Was steht in den logs und welche fehlermeldungen kommen.
Wenn Du Dein Auto in die Werkstatt bringst und denen einfach nru sagst: Tut nich' werden die Dich auch fragen, was nicht tutet.
Kann mir jemand sagen ob die Anleitung was taugt oder muss ich Grundlegend etwas anders machen?
Prinzipiell ist die Anleitung in Ordnung. Grundlegend muß aber Dein Problem zu der Anleitung passen.
Wenn das dann funktioniert möchte ich den Tunnel dann auf ein Gerät was im selben Lan wie das Gerät A ist erweitern.
Was genaue meinst Du damit?
Das Gerät ist eine SPS und ich muss eine änderung machen. Ich darf im Moment nicht zu diesem Gerät hin fahren.
Die Sps hört auf Port 900.
Mir steht ein Debian Server mit Fixer Ip zur Verfügung.
Die Sps hört auf Port 900.
Mir steht ein Debian Server mit Fixer Ip zur Verfügung.
Mal mal ein Schaubild und scheibe dazu wo die Geräte stehen, wo ein Tunnel hinsoll, was die firewall durchläßt und ob irgendwelche fernwartungszugänge schon eingerichtet sind.
Es ist nicht ganz klar, ob z.B. Dein Debianserver irgendwo in der Wolke steht oder ob im selben LAN oder Standort wie die SPS.
Sobald Du Dein Problem richtig beschreibst ist die Lösung vermutlich trivial.
lks
Mal mal ein Schaubild und scheibe dazu wo die Geräte stehen, wo ein Tunnel hinsoll, was die firewall durchläßt und ob irgendwelche fernwartungszugänge schon eingerichtet sind.
Es ist nicht ganz klar, ob z.B. Dein Debianserver irgendwo in der Wolke steht oder ob im selben LAN oder Standort wie die SPS.
Sobald Du Dein Problem richtig beschreibst ist die Lösung vermutlich trivial.
lks
Es ist nicht ganz klar, ob z.B. Dein Debianserver irgendwo in der Wolke steht oder ob im selben LAN oder Standort wie die SPS.
Sobald Du Dein Problem richtig beschreibst ist die Lösung vermutlich trivial.
lks
Also ich kann auf beiden Seiten auf den Debian Server zugreifen aber der Test mit VNC geht nicht.
Hier das Bild
Lg und Danke
Moin,
Allerdings ist es eher hinderlich, dass Server A über einen Surfstick angebunden ist, über welchen Anbieter läuft der Stick (Telekom, Vodafone, Telefonica o2/E-Plus)?
Auf der SPS wird ganz sicher kein VNC laufen, aber man kann natürlich auch Telnet oder ssh zusätzlich tunneln oder - wenn man die Ports genau weiss - auch Spezialanwendungen.
Gruß
cykes
Zitat von @SonnenTony:
Also ich kann auf beiden Seiten auf den Debian Server zugreifen aber der Test mit VNC geht nicht.
Dazu muss VNC natürlich auch auf der Zielmaschine laufen. Aber schon mal gut zu wissen, dass Du (anderweitigen) Zugriff auf Server A hast.Also ich kann auf beiden Seiten auf den Debian Server zugreifen aber der Test mit VNC geht nicht.
Allerdings ist es eher hinderlich, dass Server A über einen Surfstick angebunden ist, über welchen Anbieter läuft der Stick (Telekom, Vodafone, Telefonica o2/E-Plus)?
Auf der SPS wird ganz sicher kein VNC laufen, aber man kann natürlich auch Telnet oder ssh zusätzlich tunneln oder - wenn man die Ports genau weiss - auch Spezialanwendungen.
Gruß
cykes
Der Pc "A" läuft mit Vodafone. VNC läuft auf der Maschine. NUr nicht über den Tunnel 
.Was ist bei Surfstick nicht gut?
Die SPS lauscht auf Port900.
Funktioniert mit Putty und einem Reverse Tunnel ?
Wie stellt man das Vorgehen am besten an?
Danke für die Hilfe
.Was ist bei Surfstick nicht gut?Die SPS lauscht auf Port900.
Funktioniert mit Putty und einem Reverse Tunnel ?
Wie stellt man das Vorgehen am besten an?
Danke für die Hilfe
Steht denn der ssh-Tunnel zwischen Deinem Debian-Server und dem Server A, ist der Surfstick via DynDNS erreichbar oder nicht? Du musst ja den Tunnel umgekehrt aufbauen, also Dein Debian-Server baut den Tunnel zum Surfstick auf, klappt das zumindest - ich vermute eher nein, da der Surfstick im Vodafone CGN liegt und nur via IPv6 erreichbar wäre, wenn überhaupt.
Zitat von @cykes:
Steht denn der ssh-Tunnel zwischen Deinem Debian-Server und dem Server A, ist der Surfstick via DynDNS erreichbar oder nicht? Du musst ja den Tunnel umgekehrt aufbauen, also Dein Debian-Server baut den Tunnel zum Surfstick auf, klappt das zumindest - ich vermute eher nein, da der Surfstick im Vodafone CGN liegt und nur via IPv6 erreichbar wäre, wenn überhaupt.
Steht denn der ssh-Tunnel zwischen Deinem Debian-Server und dem Server A, ist der Surfstick via DynDNS erreichbar oder nicht? Du musst ja den Tunnel umgekehrt aufbauen, also Dein Debian-Server baut den Tunnel zum Surfstick auf, klappt das zumindest - ich vermute eher nein, da der Surfstick im Vodafone CGN liegt und nur via IPv6 erreichbar wäre, wenn überhaupt.
Ich habe wie in der Anleitung https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/
Auf dem Rechner A eine Verbindung zum Debian Server B aufgemacht. Mit dem Umweg über den Server B der eine Fixe Ip hat sollte ich kein Dyn DNS brauchen. Oder verstehe ich das falsch?
Zitat von @SonnenTony:
Ich habe wie in der Anleitung https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/
Hast Du offenbar nicht. Da steht eindeutig unter Punkt 1. Setup putty to SSH from A to B -> Hostname: yourhost.dyndns.org - das ist in dem Fall Host A bzw. dessen Internet-Verbindung - also der Surfstick in Deinem Fall (hast Du die öffentliche IP des Sticks oder nicht)?Ich habe wie in der Anleitung https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/
Auf dem Rechner A eine Verbindung zum Debian Server B aufgemacht. Mit dem Umweg über den Server B der eine Fixe Ip hat sollte ich kein Dyn DNS brauchen. Oder verstehe ich das falsch?
Das hast Du falsch verstanden, Du benötigst in jedem Fall die öffentliche IP von Server A (also dem Surfstick in Deinem Fall, kann auch die direkte IP sein, dann brauchst Du kein dyndns, macht das Leben aber einfacher. Wobei das mit hoher Wahrscheinlichkeit nicht über die Mobilverbindung funktionieren wird.Zitat von @cykes:
Zitat von @SonnenTony:
Ich habe wie in der Anleitung https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/
Hast Du offenbar nicht. Da steht eindeutig unter Punkt 1. Setup putty to SSH from A to B -> Hostname: yourhost.dyndns.org - das ist in dem Fall Host A bzw. dessen Internet-Verbindung - also der Surfstick in Deinem Fall (hast Du die öffentliche IP des Sticks oder nicht)?Ich habe wie in der Anleitung https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/
Auf dem Rechner A eine Verbindung zum Debian Server B aufgemacht. Mit dem Umweg über den Server B der eine Fixe Ip hat sollte ich kein Dyn DNS brauchen. Oder verstehe ich das falsch?
Das hast Du falsch verstanden, Du benötigst in jedem Fall die öffentliche IP von Server A (also dem Surfstick in Deinem Fall, kann auch die direkte IP sein, dann brauchst Du kein dyndns, macht das Leben aber einfacher. Wobei das mit hoher Wahrscheinlichkeit nicht über die Mobilverbindung funktionieren wird.Bitte entschuldige meine Dummen Fragen aber warum Benötige ich dann Den Debianserver in der MItte? Da könnte ich ja von C direkt auf A zugreifen oder?
Wie gesagt ich bin absolut nicht Fit bei dem Zeug aber ich verstehe nicht was dann der Sever B hilft.
Danke für die Hilfe
Zitat von @SonnenTony:
Bitte entschuldige meine Dummen Fragen aber warum Benötige ich dann Den Debianserver in der MItte? Da könnte ich ja von C direkt auf A zugreifen oder?
Es gibt keine dummen Fragen, man muss die Fragen nur richtig stellen Bitte entschuldige meine Dummen Fragen aber warum Benötige ich dann Den Debianserver in der MItte? Da könnte ich ja von C direkt auf A zugreifen oder?
Der Trick an der Sache ist, dass Du über den Server B eine (mehr oder weniger) permanente Tunnelverbindung zu Server A hast und Du durch den Tunnel entprechende Dienste auf Server A (bspw. VNC, ssh, ftp usw.) ansprechen kannst, die bei einer direkten ssh Verbindung von C nach A nicht ansprechbar wären. Das wird in der Anleitung unter Punkt 2. (Tunnel configuration) am Beispiel von VNC erklärt, dazu muss natürlich auf A VNC(-Server) auch laufen - geht aber auch mit jeglichem anderen Dienst, der direkt "von außen" nicht erreichbar ist. ssh muss natürlich auf Server A auf Port 22 von außen erreichbar sein. Daran wird es bei Deinem Setup vermutlich scheitern.Wie gesagt ich bin absolut nicht Fit bei dem Zeug aber ich verstehe nicht was dann der Sever B hilft.
Er macht das Port-Forwarding durch den Tunnel. Er stellt eine Brücke dar.Gruß
cykes
Zitat von @SonnenTony:
Der Pc "A" läuft mit Vodafone. VNC läuft auf der Maschine. NUr nicht über den Tunnel.Was ist bei Surfstick nicht gut?
Die SPS lauscht auf Port900.
Funktioniert mit Putty und einem Reverse Tunnel ?
Der Pc "A" läuft mit Vodafone. VNC läuft auf der Maschine. NUr nicht über den Tunnel
.Was ist bei Surfstick nicht gut?Die SPS lauscht auf Port900.
Funktioniert mit Putty und einem Reverse Tunnel ?
Ja.
Wie stellt man das Vorgehen am besten an?
- Du machst von C eine ssh-verbindung zu B mit einem Tunnel, der den lokalen Port (5)900 auf den Debian-Server auf localhost: (5)900 weiterleitet.
- Du machst von A eine ssh-verbindung zu B mit einem Reverse Tunnel der dort den Port (5)900 auf die SPS lokal weiterleitet.
- Du verbindest auf C VNC mit dem lokalen Port (5)900 auf C.
Durch die beiden Tunnel sollte dann der VNC-Viewer auf dem SPS landen.
lks
Zitat von @cykes:
Der Trick an der Sache ist, dass Du über den Server B eine (mehr oder weniger) permanente Tunnelverbindung zu Server A hast und Du durch den Tunnel entprechende Dienste auf Server A (bspw. VNC, ssh, ftp usw.) ansprechen kannst, die bei einer direkten ssh Verbindung von C nach A nicht ansprechbar wären. Das wird in der Anleitung unter Punkt 2. (Tunnel configuration) am Beispiel von VNC erklärt, dazu muss natürlich auf A VNC(-Server) auch laufen - geht aber auch mit jeglichem anderen Dienst, der direkt "von außen" nicht erreichbar ist. ssh muss natürlich auf Server A auf Port 22 von außen erreichbar sein. Daran wird es bei Deinem Setup vermutlich scheitern.
Gruß
cykes
Zitat von @SonnenTony:
Bitte entschuldige meine Dummen Fragen aber warum Benötige ich dann Den Debianserver in der MItte? Da könnte ich ja von C direkt auf A zugreifen oder?
Es gibt keine dummen Fragen, man muss die Fragen nur richtig stellen Bitte entschuldige meine Dummen Fragen aber warum Benötige ich dann Den Debianserver in der MItte? Da könnte ich ja von C direkt auf A zugreifen oder?
Der Trick an der Sache ist, dass Du über den Server B eine (mehr oder weniger) permanente Tunnelverbindung zu Server A hast und Du durch den Tunnel entprechende Dienste auf Server A (bspw. VNC, ssh, ftp usw.) ansprechen kannst, die bei einer direkten ssh Verbindung von C nach A nicht ansprechbar wären. Das wird in der Anleitung unter Punkt 2. (Tunnel configuration) am Beispiel von VNC erklärt, dazu muss natürlich auf A VNC(-Server) auch laufen - geht aber auch mit jeglichem anderen Dienst, der direkt "von außen" nicht erreichbar ist. ssh muss natürlich auf Server A auf Port 22 von außen erreichbar sein. Daran wird es bei Deinem Setup vermutlich scheitern.Wie gesagt ich bin absolut nicht Fit bei dem Zeug aber ich verstehe nicht was dann der Sever B hilft.
Er macht das Port-Forwarding durch den Tunnel. Er stellt eine Brücke dar.Gruß
cykes
Ok danke für die Erklärung.
Kann man es nicht so machen das man den Tunnel vo n A nach B und von C nach B aufmacht und dann irgendwie von c auf a ohne Dyndns durch kommunizieren kann?
Zitat von @SonnenTony:
Kann man es nicht so machen das man den Tunnel vo n A nach B und von C nach B aufmacht und dann irgendwie von c auf a ohne Dyndns durch kommunizieren kann?
Kann man es nicht so machen das man den Tunnel vo n A nach B und von C nach B aufmacht und dann irgendwie von c auf a ohne Dyndns durch kommunizieren kann?
Hast Du denn nicht gelesen, was ich geschrieben habe?
Genau das ist das korrekte vorgehen, wenn man ohne dyndns arbeiten will.
lks
Zitat von @Lochkartenstanzer:
Hast Du denn nicht gelesen, was ich geschrieben habe?
Genau das ist das korrekte vorgehen, wenn man ohne dyndns arbeiten will.
lks
Sorry den Beitrag hatte ich nicht gesehen. Wie kann man das Debuggen? Werde es ausprobierenZitat von @SonnenTony:
Kann man es nicht so machen das man den Tunnel vo n A nach B und von C nach B aufmacht und dann irgendwie von c auf a ohne Dyndns durch kommunizieren kann?
Kann man es nicht so machen das man den Tunnel vo n A nach B und von C nach B aufmacht und dann irgendwie von c auf a ohne Dyndns durch kommunizieren kann?
Hast Du denn nicht gelesen, was ich geschrieben habe?
Genau das ist das korrekte vorgehen, wenn man ohne dyndns arbeiten will.
lks
- Du baust den Tunnel A auf B auf und machst ein telnet auf B auf den Port, der weitergeleitet werden soll. Wenn der Tunnel steht, bekommst Du eine Verbindung aber nur einen scharzen Bildschirm. Du kannst allerdings mit Wireshark auf A schauen, ob die Pakete korrekt aus dem Tunnel kommen udn ans richtige Ziel gehen.
- Du baust einen Tunnel von C zu B auf und schaust mit Telnet, ob einen Verbindung zustandekommt. Im Problemfall kannst Du mit tcpdump oder wireshark auf B und C schauen, ob die Pakete aus den Tunnel richtig kommen udn weitergeleitet werden.
lks
Hallo,
in Putty trägst Du unter SSH/Tunnels folgendes ein:
Source Port: 901
Destination: 192.168.1.200:900
...und klickst auf "Add".
Danach baust Du die SSH-Verbindung zum Rechner 192.168.1.20 auf und kannst mit deiner Applikation auf localhost Port 901 zugreifen. Dieser wird dann auf Port 900 der SPS (und zurück) getunnelt.
Gruß,
Jörg
in Putty trägst Du unter SSH/Tunnels folgendes ein:
Source Port: 901
Destination: 192.168.1.200:900
...und klickst auf "Add".
Danach baust Du die SSH-Verbindung zum Rechner 192.168.1.20 auf und kannst mit deiner Applikation auf localhost Port 901 zugreifen. Dieser wird dann auf Port 900 der SPS (und zurück) getunnelt.
Gruß,
Jörg
Zitat von @Lochkartenstanzer:
lks
- Du baust den Tunnel A auf B auf und machst ein telnet auf B auf den Port, der weitergeleitet werden soll. Wenn der Tunnel steht, bekommst Du eine Verbindung aber nur einen scharzen Bildschirm. Du kannst allerdings mit Wireshark auf A schauen, ob die Pakete korrekt aus dem Tunnel kommen udn ans richtige Ziel gehen.
- Du baust einen Tunnel von C zu B auf und schaust mit Telnet, ob einen Verbindung zustandekommt. Im Problemfall kannst Du mit tcpdump oder wireshark auf B und C schauen, ob die Pakete aus den Tunnel richtig kommen udn weitergeleitet werden.
lks
Wenn ich nach dem Aufbau des Tunnels versuche eine Telnet Verbindung auf Localhost:900 zu machen, dann erscheint im Telnet Fenster der Fehler RFB 003.008 und die Verbindung bricht ab.
Die Tunnels habe ich wie in den Bildern ersichtlich aufgebaut.
Einstellung von Rechner C
Hallo,
und warum greifst Du auf Port 900 zu während Du lokal - in beiden Beispielen - 10001 konfiguriert hast?
Das zweite Beispiel müsste richtig sein. Damit ssh auf die .20 und mit Port 10001 sprechen...
Gruß,
Jörg
und warum greifst Du auf Port 900 zu während Du lokal - in beiden Beispielen - 10001 konfiguriert hast?
Das zweite Beispiel müsste richtig sein. Damit ssh auf die .20 und mit Port 10001 sprechen...
Gruß,
Jörg
Also das erste Bild ist vom Rechner C das zweite vom Rechner A
Ich möchte ja den Port ja auf dem Rechner C auf die Ip192.168.1.200:900 zugreifen.
Dafür stelle ich auf dem Rechner c im VNC viewer Localhost:901 ein.
Danke für die Hilfe
Ich möchte ja den Port ja auf dem Rechner C auf die Ip192.168.1.200:900 zugreifen.
Dafür stelle ich auf dem Rechner c im VNC viewer Localhost:901 ein.
Danke für die Hilfe
Hallo,
lies meinen Beitrag. Du brauchst nur ein putty und verbindest dich via ssh auf 192.168.1.20
Dabei wird dann der in putty eingestellte Tunnel gezogen.
Gruß,
Jörg
lies meinen Beitrag. Du brauchst nur ein putty und verbindest dich via ssh auf 192.168.1.20
Dabei wird dann der in putty eingestellte Tunnel gezogen.
Gruß,
Jörg
Wie ich brauche nur ein Putty?
Wie soll mein Rechner C wissen wo Der Rechner A ist wenn ich nicht auch von Rechner C einen Tunnel zu B aufbaue?
Hast du das Bild meiner Anforderung oben gesehen?
Sorry wenn ich mich doof anstelle aber das ist nicht mein Gebiet.
Wie soll mein Rechner C wissen wo Der Rechner A ist wenn ich nicht auch von Rechner C einen Tunnel zu B aufbaue?
Hast du das Bild meiner Anforderung oben gesehen?
Sorry wenn ich mich doof anstelle aber das ist nicht mein Gebiet.
Hallo,
Rechner C schickt die Antworten dorthin woher die Fragen kommen. Also zu Rechner B. Und Rechner B schubst die wieder zurück zum Putty.
Gruß,
Jörg
Rechner C schickt die Antworten dorthin woher die Fragen kommen. Also zu Rechner B. Und Rechner B schubst die wieder zurück zum Putty.
Gruß,
Jörg
Zitat von @117471:
Hallo,
Rechner C schickt die Antworten dorthin woher die Fragen kommen. Also zu Rechner B. Und Rechner B schubst die wieder zurück zum Putty.
Gruß,
Jörg
Das funktioniert nur wenn man auf der Debian Maschine "B" in der /etc/ssh/sshd_config "GatewayPorts" auf "yes" stelltHallo,
Rechner C schickt die Antworten dorthin woher die Fragen kommen. Also zu Rechner B. Und Rechner B schubst die wieder zurück zum Putty.
Gruß,
Jörg
Dann funktioniert es anstandslos.
Besser würde es mir aber mit dem zweiten Tunnel von C auf B gefallen.
Weiß jemand was man da machen muss?
Hallo,
tut mir leid. Ich kenne nur die von mir gepostete Lösung.
Bei mir funktioniert es immer mit den Standardeinstellungen.
Gruß,
Jörg
tut mir leid. Ich kenne nur die von mir gepostete Lösung.
Bei mir funktioniert es immer mit den Standardeinstellungen.
Gruß,
Jörg
Schade das du nicht weiter weißt.
Trotzdem Danke
Trotzdem Danke
Hallo,
naja - so wie ich geschrieben habe funktioniert es ja
Gruß,
Jörg
naja - so wie ich geschrieben habe funktioniert es ja
Gruß,
Jörg
Zitat von @117471:
Hallo,
naja - so wie ich geschrieben habe funktioniert es ja
Gruß,
Jörg
Hallo,
naja - so wie ich geschrieben habe funktioniert es ja
Gruß,
Jörg
Ja es funktioniert wie du sagst wenn man am SSH-Server den getunnelten Port auch Verbindungen von außen
zulässt.
Ich weiß dabei nur nicht wie kritisch dies für die Sicherheit ist.
Sehr kritisch!
lks
Ok würdest du mir Helfen den Tunnel von C zu B in griff zu bekommen?
Möchte nämlich eine Sichere Variante verwenden.
Danke Für die Hilfe
Hallo,
Das hängt davon ab, inwiefern Du der SSH-Konfiguration traust. Bei meinem Servern ist ein SSH-Root-Login ausschließlich über authorized Keys möglich, wobei nur mein eigener (passwortgeschützter) Schlüssel freigeschaltet ist.
Das erachte ich als vertrauenswürdig, zumal ja nur der eine Port getunnelt wird. Würden alle Ports getunnelt werden (also z.B. auch SMB usw.), müsste man sich halt noch mal die Sicherheit des eigenen Client-Rechners angucken bevor man damit ein fremdes Netz kontaktiert.
Gruß,
Jörg
Das hängt davon ab, inwiefern Du der SSH-Konfiguration traust. Bei meinem Servern ist ein SSH-Root-Login ausschließlich über authorized Keys möglich, wobei nur mein eigener (passwortgeschützter) Schlüssel freigeschaltet ist.
Das erachte ich als vertrauenswürdig, zumal ja nur der eine Port getunnelt wird. Würden alle Ports getunnelt werden (also z.B. auch SMB usw.), müsste man sich halt noch mal die Sicherheit des eigenen Client-Rechners angucken bevor man damit ein fremdes Netz kontaktiert.
Gruß,
Jörg
Soory wenn ich nochmal Frage, ich habe mir jetzt Wireshark besorgt.
Leider blicke ich wie das Schwein in Uhrwerk. Ich möchte den Tunnel von C zu B debuggen.
Danke für die Hilfe
Leider blicke ich wie das Schwein in Uhrwerk. Ich möchte den Tunnel von C zu B debuggen.
Danke für die Hilfe
Hallo,
Ich ehrlich gesagt auch. Was zum Geier möchtest Du da "debuggen"?
Gruß,
Jörg
Ich ehrlich gesagt auch. Was zum Geier möchtest Du da "debuggen"?
Gruß,
Jörg
Ich möchte mit dem zweiten Tunnel von C auf b einen Tunnel aufbauen. Dies Funktioniert nicht. Deshalb möchte ich irgendwie den Fehler finden.
Ein Wireshark Tutorial würde hier deutlich den Rahmen sprengen. Das ist nicht mit zwei Sätzen erklärt.
Vielleicht schaust Du Dir mal folgendes an: http://www.nwlab.net/tutorials/wireshark/
Eine genau für Deinen Anwendungsfall zugeschnittene Anleitung wirst Du aber nicht finden. Probiere also erstmal damit aus, und frag dann wenn Du irgendwo hängst spezifischer nach.
Vielleicht schaust Du Dir mal folgendes an: http://www.nwlab.net/tutorials/wireshark/
Eine genau für Deinen Anwendungsfall zugeschnittene Anleitung wirst Du aber nicht finden. Probiere also erstmal damit aus, und frag dann wenn Du irgendwo hängst spezifischer nach.
Hallo,
natürlich funktioniert es nicht. Oder kannst Du mit deinem Auto gleichzeitig vorwärts und rückwärts fahren?
Wer sagt denn, dass das möglich ist? Er möge es bitte hier im Forum vorführen. Wir sind alle gespannt!
Gruß,
Jörg
natürlich funktioniert es nicht. Oder kannst Du mit deinem Auto gleichzeitig vorwärts und rückwärts fahren?
Wer sagt denn, dass das möglich ist? Er möge es bitte hier im Forum vorführen. Wir sind alle gespannt!
Gruß,
Jörg
Wiso soll das nicht gehen?
Ich meine es sollte doch das selbe sein wenn ich mit dem Rechner C über einen Tunnel auf B zugreife . Mit Deiner Methode greife ich ja auch von C auf B zu nur ohne Tunnel.
Oder wo ist meine Denke falsch?
Danke für die Hilfe
Ich meine es sollte doch das selbe sein wenn ich mit dem Rechner C über einen Tunnel auf B zugreife . Mit Deiner Methode greife ich ja auch von C auf B zu nur ohne Tunnel.
Oder wo ist meine Denke falsch?
Danke für die Hilfe
Hallo,
es ist schlichtweg kein „Tunnel“, sondern lediglich eine Weiterleitung von Datenpaketen über SSH.
Vielleicht wurde da irgendwo eine unglückliche Begrifflichkeit gewählt. Aber eine Weiche ist z.B. auch eine Abzweigung für Züge oder wahlweise eine korpulente Frau.
Ein Tunnel wäre z.B. eine Lösung via ipsec oder openvpn. Das wiederum wäre aber mit umfangreichen Installationsarbeiten und ggf. Anpassungen an den Netzen verbunden. Und deutlich unsicherer wäre es auch, da das ganze Netz mit offenem Visier vor dir steht und nicht nur ein Port eines Hosts...
Gruß,
Jörg
es ist schlichtweg kein „Tunnel“, sondern lediglich eine Weiterleitung von Datenpaketen über SSH.
Vielleicht wurde da irgendwo eine unglückliche Begrifflichkeit gewählt. Aber eine Weiche ist z.B. auch eine Abzweigung für Züge oder wahlweise eine korpulente Frau.
Ein Tunnel wäre z.B. eine Lösung via ipsec oder openvpn. Das wiederum wäre aber mit umfangreichen Installationsarbeiten und ggf. Anpassungen an den Netzen verbunden. Und deutlich unsicherer wäre es auch, da das ganze Netz mit offenem Visier vor dir steht und nicht nur ein Port eines Hosts...
Gruß,
Jörg
Zitat von @117471:
Hallo,
es ist schlichtweg kein „Tunnel“, sondern lediglich eine Weiterleitung von Datenpaketen über SSH.
Vielleicht wurde da irgendwo eine unglückliche Begrifflichkeit gewählt. Aber eine Weiche ist z.B. auch eine Abzweigung für Züge oder wahlweise eine korpulente Frau.
Ein Tunnel wäre z.B. eine Lösung via ipsec oder openvpn. Das wiederum wäre aber mit umfangreichen Installationsarbeiten und ggf. Anpassungen an den Netzen verbunden. Und deutlich unsicherer wäre es auch, da das ganze Netz mit offenem Visier vor dir steht und nicht nur ein Port eines Hosts...
Gruß,
Jörg
Hallo,
es ist schlichtweg kein „Tunnel“, sondern lediglich eine Weiterleitung von Datenpaketen über SSH.
Vielleicht wurde da irgendwo eine unglückliche Begrifflichkeit gewählt. Aber eine Weiche ist z.B. auch eine Abzweigung für Züge oder wahlweise eine korpulente Frau.
Ein Tunnel wäre z.B. eine Lösung via ipsec oder openvpn. Das wiederum wäre aber mit umfangreichen Installationsarbeiten und ggf. Anpassungen an den Netzen verbunden. Und deutlich unsicherer wäre es auch, da das ganze Netz mit offenem Visier vor dir steht und nicht nur ein Port eines Hosts...
Gruß,
Jörg
Das mag ja alle sein.
Meine Überlegung ist nur die wenn ich von C aus auf B über seine IP Plus dem Port der zu A zeigt und dies Funktioniert dann sollte es doch auch gehen wenn ich mit SSh von C auf B zugreife es ist im Grunde doch auch nur eine Verbindung zum Host.
Bitte entschuldige meine Hartnäckigkeit aber ich verstehe nicht wo der Unterschied ist.
Sollte, könnte...ziemlich viel Konjunktiv. Die Frage ist doch WARUM du dir nicht einfach mal einen Wireshark oder tcpdump nimmst und das mal GENAU selber ansiehst. Dann hast du doch absolute technisches Gewissheit und musst dich nicht auf endloses Rumraten in Foren verlassen.
Hallo,
aus dem gleichen Grund, warum ein Toaster keinen Kaffee kocht: Weil die Software genau so für diesen Zweck entwickelt wurde. Etwas Anderes kann man damit halt nicht machen?!?
Die Motivation für diese Entwicklung war vermutlich die Flexibilität, die Einfachheit und die Sicherheit gegenüber einem Netzwerktunnel.
geduldiger Gruß,
Jörg
aus dem gleichen Grund, warum ein Toaster keinen Kaffee kocht: Weil die Software genau so für diesen Zweck entwickelt wurde. Etwas Anderes kann man damit halt nicht machen?!?
Die Motivation für diese Entwicklung war vermutlich die Flexibilität, die Einfachheit und die Sicherheit gegenüber einem Netzwerktunnel.
geduldiger Gruß,
Jörg
Zitat von @aqui:
Sollte, könnte...ziemlich viel Konjunktiv. Die Frage ist doch WARUM du dir nicht einfach mal einen Wireshark oder tcpdump nimmst und das mal GENAU selber ansiehst. Dann hast du doch absolute technisches Gewissheit und musst dich nicht auf endloses Rumraten in Foren verlassen.
Sollte, könnte...ziemlich viel Konjunktiv. Die Frage ist doch WARUM du dir nicht einfach mal einen Wireshark oder tcpdump nimmst und das mal GENAU selber ansiehst. Dann hast du doch absolute technisches Gewissheit und musst dich nicht auf endloses Rumraten in Foren verlassen.
Ich hatte gestern versucht mit Wireshark zu sehen was beim Aufbau des Tunnels zwischen C & B passiert, leider reichen meine Kenntnisse nicht.
Ich brauche etwas Hilfe dabei.
Wenn das hier https://blog.devolutions.net/2017/04/how-to-configure-an-ssh-tunnel-on-p ... funktioniert dann muss es auch möglich sein von B weiter zu A zu kommen.
Hallo,
nein - das sind völlig unterschiedliche Dinge.
Das Einzige, was sie gemeinsam haben ist, dass sie „Tunnel“ genannt werden.
Die haben miteinander nichts zu tun. Genau so wenig, wie sie z.B. mit dem Tunnel für die Lokomotive zu tun haben.
Es ist lediglich das gleiche Wort für unterschiedliche Sachen verwendet worden. Mehr nicht.
Das, was deine Grafik darstellt kenne ich nicht und ich habe so etwas in den letzten 35 Jahren auch noch nie gesehen.
immer noch geduldig,
Jörg
nein - das sind völlig unterschiedliche Dinge.
Das Einzige, was sie gemeinsam haben ist, dass sie „Tunnel“ genannt werden.
Die haben miteinander nichts zu tun. Genau so wenig, wie sie z.B. mit dem Tunnel für die Lokomotive zu tun haben.
Es ist lediglich das gleiche Wort für unterschiedliche Sachen verwendet worden. Mehr nicht.
Das, was deine Grafik darstellt kenne ich nicht und ich habe so etwas in den letzten 35 Jahren auch noch nie gesehen.
immer noch geduldig,
Jörg
Also du sagst das diese Anleitung https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/
nichts taugt und falsch ist?
Was ist mit dieser Aussage von Reverse SSH Tunnel mit Putty unter Windows bauen
Danke für deine Geduld.
Ich ,möchte deine Erfahrung nicht anzweifeln .
Also du sagst das diese Anleitung https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/
nichts taugt und falsch ist?
Was ist mit dieser Aussage von Reverse SSH Tunnel mit Putty unter Windows bauen
Danke für deine Geduld.
Ich ,möchte deine Erfahrung nicht anzweifeln .
nichts taugt und falsch ist?
Was ist mit dieser Aussage von Reverse SSH Tunnel mit Putty unter Windows bauen
Danke für deine Geduld.
Ich ,möchte deine Erfahrung nicht anzweifeln .
Zitat von @117471:
Hallo,
nein - das sind völlig unterschiedliche Dinge.
Das Einzige, was sie gemeinsam haben ist, dass sie „Tunnel“ genannt werden.
Die haben miteinander nichts zu tun. Genau so wenig, wie sie z.B. mit dem Tunnel für die Lokomotive zu tun haben.
Es ist lediglich das gleiche Wort für unterschiedliche Sachen verwendet worden. Mehr nicht.
Das, was deine Grafik darstellt kenne ich nicht und ich habe so etwas in den letzten 35 Jahren auch noch nie gesehen.
immer noch geduldig,
Jörg
Zitat von @117471:
Hallo,
nein - das sind völlig unterschiedliche Dinge.
Das Einzige, was sie gemeinsam haben ist, dass sie „Tunnel“ genannt werden.
Die haben miteinander nichts zu tun. Genau so wenig, wie sie z.B. mit dem Tunnel für die Lokomotive zu tun haben.
Es ist lediglich das gleiche Wort für unterschiedliche Sachen verwendet worden. Mehr nicht.
Das, was deine Grafik darstellt kenne ich nicht und ich habe so etwas in den letzten 35 Jahren auch noch nie gesehen.
immer noch geduldig,
Jörg
Zitat von @117471:
Also du sagst das diese Anleitung https://vincetocco.com/how-to-setup-a-reverse-tunnel-with-putty/
nichts taugt und falsch ist?
Was ist mit dieser Aussage von Reverse SSH Tunnel mit Putty unter Windows bauen
Danke für deine Geduld.
Ich ,möchte deine Erfahrung nicht anzweifeln .
Hallo,
es gibt eine „Flat earth society“ die die Meinung vertritt, dass die Erde eine Scheibe ist.
Die haben 3500 Mitglieder. Meinst Du, dass die alle falsch liegen?
Meine Erfahrung ist, dass die Leute mit viel Ahnung eher selten Videos und Tutorials veröffentlichen - das sind eher diejenigen, die von Aufmerksamkeit leben. Egal ob im negativen oder positiven Sinn.
Frag' doch mal die Verfasser deiner Anleitungen. Vielleicht sind die ja auch so geduldig und auf deren Erklärung sind wir alle gespannt.
Abgesehen davon, dass der Putty-Tunnel mit dem gespiegelten Port die sicherste Lösung ist.
Liebe Grüße aus Bremen,
Jörg
es gibt eine „Flat earth society“ die die Meinung vertritt, dass die Erde eine Scheibe ist.
Die haben 3500 Mitglieder. Meinst Du, dass die alle falsch liegen?
Meine Erfahrung ist, dass die Leute mit viel Ahnung eher selten Videos und Tutorials veröffentlichen - das sind eher diejenigen, die von Aufmerksamkeit leben. Egal ob im negativen oder positiven Sinn.
Frag' doch mal die Verfasser deiner Anleitungen. Vielleicht sind die ja auch so geduldig und auf deren Erklärung sind wir alle gespannt.
Abgesehen davon, dass der Putty-Tunnel mit dem gespiegelten Port die sicherste Lösung ist.
Liebe Grüße aus Bremen,
Jörg
Habe jetzt beiden eine Nachricht geschrieben mal sehen ob Lochkartenstanzer und der Verfasser der Anleitung antworten.
Moin,,
Also wenn Du folgendes machst:
Auf A (192.168.1.20):
und auf C
kannst Du dann mit
Von C auf die SPS zugreifen.
Habe das vorhin einfach zum Test mal durchgespielt.
Dabei mußt Du die SSH-paramter an Putty anpassen und statt dem vncviewer Deine VNC-Client nehmen.
Achtung: Du mußt bei den Ports aufpassen, weil Ports unter 1024 root-rechte benötigen und daher auf dem debian als Zwischenstation ggf nicht funktionieren, wenn Du nur als normaler user draufgehst.
debuggen kann man übrigens mit tcpdump auf dem debian-server.
lks
Also wenn Du folgendes machst:
Auf A (192.168.1.20):
ssh -R 9000:192.168.1.200:900 user@B-Remote-SSH-Server -N
und auf C
ssh -L 9000:127.0.0.1:9000 user@B-Remote-SSH-Server -N
kannst Du dann mit
vncviewer 127.0.0.1:9000
Von C auf die SPS zugreifen.
Habe das vorhin einfach zum Test mal durchgespielt.
Dabei mußt Du die SSH-paramter an Putty anpassen und statt dem vncviewer Deine VNC-Client nehmen.
Achtung: Du mußt bei den Ports aufpassen, weil Ports unter 1024 root-rechte benötigen und daher auf dem debian als Zwischenstation ggf nicht funktionieren, wenn Du nur als normaler user draufgehst.
debuggen kann man übrigens mit tcpdump auf dem debian-server.
lks
So endlich bin ich am Ziel Es Funktioniert!!!)))
Den Fehler den ich gemacht habe war das ich auf der Maschine C bei der Tunnel Konfiguration Source port und der getunnelte Port gleich sein. Dann geht es wie von alleine!
Vielen Dank allen die Geholfen haben.
Es Funktioniert!!!)))Den Fehler den ich gemacht habe war das ich auf der Maschine C bei der Tunnel Konfiguration Source port und der getunnelte Port gleich sein. Dann geht es wie von alleine!
Vielen Dank allen die Geholfen haben.
Kleine Ursache, große Wirkung !
Gut das es nun rennt. War ja ne schwere Geburt aber manchmal sieht man eben den Wald...usw.
Gut das es nun rennt. War ja ne schwere Geburt aber manchmal sieht man eben den Wald...usw.
Zitat von @aqui:
Kleine Ursache, große Wirkung !
Gut das es nun rennt. War ja ne schwere Geburt aber manchmal sieht man eben den Wald...usw.
Ja Ja man darf nur nie aufgebe.......dann rennt es auch...........Kleine Ursache, große Wirkung !
Gut das es nun rennt. War ja ne schwere Geburt aber manchmal sieht man eben den Wald...usw.
Wenn jemand noch eine Logische Erklärung hätte das wäre noch Tüpfelchen auf dem I.....
Bei einer TCP Session können doch niemals der Source und Destination Port identisch sein. Damit wäre keine TCP Session möglich.
Zitat von @aqui:
Bei einer TCP Session können doch niemals der Source und Destination Port identisch sein. Damit wäre keine TCP Session möglich.
Bei einer TCP Session können doch niemals der Source und Destination Port identisch sein. Damit wäre keine TCP Session möglich.
Jedenfalls rennt es jetzt so wie ich es wollte
