FreeSSHd und PuTTY - Ist diese Verbindung überhaupt noch verschlüsselt?
Hallo zusammen
Ich experimentiere gerade etwas mit den im Titel genannten Programmen. Es besteht dabei eine Client-Serververbindung über einen SSH-Tunnel, um Verbindungen über VNC zu tunneln. Läuft auch alles super so weit. Ich habe nur ne Frage wegen 2 Einstellungsmöglichkeiten. Eine müsste eine gesicherte Verbindung ergeben, aber bei der anderen frage ich lieber nochmal nach. Beide "Varianten" sind als Bilder angehängt, um das alles besser zu verstehen.
Variante 1: Wenn ich das alles richtig verstanden habe, laufen die Verbindungen vom VNC-Viewer in PuTTY alle auf Port 5990 (!) ein - Source port. Habe ich dort auch so eingestellt. Als "Destination" trage ich in PuTTY dann "192.168.2.194:5900" ein. Das heißt das alles, was auf dem Client auf Port 5990 einläuft nach "192.168.2.194:5900" gesendet wird. Dieses Forwarding funktioniert aber nur, wenn eine SSH-Verbindung besteht und Loopback-Verbindungen im VNC-Server deaktiviert sind. Hier zweifle ich, ob eine Verschlüsselung besteht. Laufen die Daten hier überhaupt über den Tunnel, oder findet lediglich ein Forwarding statt?
Variante 2: Hier laufen die Daten vom VNC-Viewer wiederum in PuTTY auf Port 5990 (!) ein - Source port. Als "Destination" trage ich nun aber in PuTTY "127.0.0.1:5900" ein. Jetzt schickt doch VNC seine Daten an den Port 5990, von da an werden sie nun - immer noch auf dem Client - vom Localhost (dem SSH-Client, der die Verbindung stellt) verarbeitet und danach auf Port 5900 weggeschickt. Jetzt müssten sie verschlüsselt sein, oder? Weil hier das Ziel der VNC-Daten ja eindeutig der Client selbst ist. Oder irre ich mich hier? Für Variante 2 müssen Loopback-Verbindungen erlaubt sein / auf "only loopback connections" stehen im VNC-Server.
Nun die Frage: Welche der beiden Varianten findet verschlüsselt statt? Oder finden gar BEIDE VARIANTEN verschlüsselt statt, weil bei beiden eine Verbindung zwischen freeSSHd und PuTTY bestehen muss?
Ich experimentiere gerade etwas mit den im Titel genannten Programmen. Es besteht dabei eine Client-Serververbindung über einen SSH-Tunnel, um Verbindungen über VNC zu tunneln. Läuft auch alles super so weit. Ich habe nur ne Frage wegen 2 Einstellungsmöglichkeiten. Eine müsste eine gesicherte Verbindung ergeben, aber bei der anderen frage ich lieber nochmal nach. Beide "Varianten" sind als Bilder angehängt, um das alles besser zu verstehen.
Variante 1: Wenn ich das alles richtig verstanden habe, laufen die Verbindungen vom VNC-Viewer in PuTTY alle auf Port 5990 (!) ein - Source port. Habe ich dort auch so eingestellt. Als "Destination" trage ich in PuTTY dann "192.168.2.194:5900" ein. Das heißt das alles, was auf dem Client auf Port 5990 einläuft nach "192.168.2.194:5900" gesendet wird. Dieses Forwarding funktioniert aber nur, wenn eine SSH-Verbindung besteht und Loopback-Verbindungen im VNC-Server deaktiviert sind. Hier zweifle ich, ob eine Verschlüsselung besteht. Laufen die Daten hier überhaupt über den Tunnel, oder findet lediglich ein Forwarding statt?
Variante 2: Hier laufen die Daten vom VNC-Viewer wiederum in PuTTY auf Port 5990 (!) ein - Source port. Als "Destination" trage ich nun aber in PuTTY "127.0.0.1:5900" ein. Jetzt schickt doch VNC seine Daten an den Port 5990, von da an werden sie nun - immer noch auf dem Client - vom Localhost (dem SSH-Client, der die Verbindung stellt) verarbeitet und danach auf Port 5900 weggeschickt. Jetzt müssten sie verschlüsselt sein, oder? Weil hier das Ziel der VNC-Daten ja eindeutig der Client selbst ist. Oder irre ich mich hier? Für Variante 2 müssen Loopback-Verbindungen erlaubt sein / auf "only loopback connections" stehen im VNC-Server.
Nun die Frage: Welche der beiden Varianten findet verschlüsselt statt? Oder finden gar BEIDE VARIANTEN verschlüsselt statt, weil bei beiden eine Verbindung zwischen freeSSHd und PuTTY bestehen muss?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 225591
Url: https://administrator.de/contentid/225591
Ausgedruckt am: 08.11.2024 um 05:11 Uhr
14 Kommentare
Neuester Kommentar
Hi soundinle,
alles was direkt zwischen beiden Tunnelendpunkten an Verkehr läuft, wird verschlüsselt übertragen. Sobald die Portweiterleitung aber an einen anderen Rechner im Remote-Netz geht wird alles was zwischen Remote-Tunnelendpunkt und dieser Maschine übertragen wird, nicht mehr verschlüsselt(das Ziel würde es ja nicht verstehen), also findet Verschlüsselung nur zwischen den beiden Tunnelendpunkten statt. Befindet sich der VNC-Server ebenfalls auf dem Remote-Tunnelendpunkt ist die gesamte Strecke verschlüsselt (hier ist es dann egal ob du die Loopback-Adresse angibst oder die IP die dieser Rechner im Remote-Netz hat).
Die Port-Forwardings die du in Putty angibst laufen alle über den Tunnel.
Grüße Uwe
alles was direkt zwischen beiden Tunnelendpunkten an Verkehr läuft, wird verschlüsselt übertragen. Sobald die Portweiterleitung aber an einen anderen Rechner im Remote-Netz geht wird alles was zwischen Remote-Tunnelendpunkt und dieser Maschine übertragen wird, nicht mehr verschlüsselt(das Ziel würde es ja nicht verstehen), also findet Verschlüsselung nur zwischen den beiden Tunnelendpunkten statt. Befindet sich der VNC-Server ebenfalls auf dem Remote-Tunnelendpunkt ist die gesamte Strecke verschlüsselt (hier ist es dann egal ob du die Loopback-Adresse angibst oder die IP die dieser Rechner im Remote-Netz hat).
Die Port-Forwardings die du in Putty angibst laufen alle über den Tunnel.
Grüße Uwe
Das Feld Destination kann zwei Bedeutungen haben, je nachdem ob du einen lokalen Port auf die Remoteseite weiterleitest oder einen Remoteport auf dem Server an einen Rechner in deinem lokalen Netzwerk. Du kannst das ganze also auch Rückwärts betreiben, quasi einen freien Port auf dem Server mit einem Port eines Rechners in deinem Netz verbinden.
Siehe dazu http://www.jfranken.de/homepages/johannes/vortraege/ssh2_inhalt.de.html#ToC9
Die Tunnelendpunkte sorgen immer dafür das der Traffic entschlüsselt an den entsprechenden Rechner weitergeleitet werden.
Wenn du also in Putty die Option Local aktivierst ist die Destination immer auf Remoteseite; wenn sie auf Remote steht ist Destination in deinem lokalen Netzwerk, weil du dann ja einen "Remoteport" vom Server auf ein Ziel in deinem lokalen Netzwerk weiterleitest.
Siehe dazu auch diese Grafik, denke dann wird es klar:
Grüße Uwe
Siehe dazu http://www.jfranken.de/homepages/johannes/vortraege/ssh2_inhalt.de.html#ToC9
Die Tunnelendpunkte sorgen immer dafür das der Traffic entschlüsselt an den entsprechenden Rechner weitergeleitet werden.
Wenn du also in Putty die Option Local aktivierst ist die Destination immer auf Remoteseite; wenn sie auf Remote steht ist Destination in deinem lokalen Netzwerk, weil du dann ja einen "Remoteport" vom Server auf ein Ziel in deinem lokalen Netzwerk weiterleitest.
Siehe dazu auch diese Grafik, denke dann wird es klar:
Grüße Uwe
Also, das ist so: Ein Programm kann auf einem Rechner auf unterschiedlichen Interfaces auf eingehende Verbindungen "lauschen". Hierbei ist das Loopback-Interface (127.0.0.1) auch als solch ein separates Interface zu sehen. Nun ist das bei dem SSH-Server so das wenn die Option "Loopback only" aktiviert ist, dieser auch nur auf Anfragen an dieses Loopback-Interface (also die Adresse 127.0.0.1) reagiert und auf keine anderen Anfragen auf andere Interfaces des Rechners (z.B. auf die IP-Adresse der Netzwerkkarte).
Hoffe das war jetzt für dich verständlich ausgedrückt.
Zum Hintergrund: Wenn man als Programmierer ein Programm schreibt das auf bestimmten Ports lauschen soll, muss man auch immer angeben auf welchen Interfaces es dies tun soll:
Als dann, alles Gute für 2014
Grüße Uwe
Hoffe das war jetzt für dich verständlich ausgedrückt.
Zum Hintergrund: Wenn man als Programmierer ein Programm schreibt das auf bestimmten Ports lauschen soll, muss man auch immer angeben auf welchen Interfaces es dies tun soll:
0.0.0.0:5900
würde dann bedeuten: Lausche auf allen Interfaces des Rechners (inkl. Loopbackint.)127.0.0.1:5900
würde dann bedeuten: Lausche nur auf dem LB-Interface und sonst nirgends. Also Anfragen an "192.168.2.194:5900" würden hier dann ins leere laufen, auch wenn die Anfrage vom selben Rechner kommt.Als dann, alles Gute für 2014
Grüße Uwe
Das, was ich unter "Destination" eintrage, sagt dem Server also, wo er genau lauschen soll
Nein, das ist einfach das Ziel für die Weiterleitung auf Remoteseite. 'Weiterleitung' heißt das nur weil du einen lokalen Port an ein Ziel auf der anderen Seite weiterleitest. Schau dir dazu nochmal die Bilder oben an.Wenn ich als Destination die Loopback des Servers habe, lauscht dieser dort und die
der Server lauscht nicht, er leitet die Pakete nur an die entsprechende Stelle (Interface)Wenn dort die IP der Netzwerkkarte steht, werden die Pakete zwar auch vom Server an sich selbst versandt, aber eben nicht über das Loopbackinterface. Und wenn die Destination eine ganz andere IP hat, dann baut der Server die Verbindung zu dem anderen Rechner auf, die dann ab Tunnelendpunkt auf dem Server unverschlüsselt vonstatten geht. Kann man das so sagen?
Korrekt.Wenn's das dann war, den Beitrag bitte noch auf gelöst setzen, und den(die) entsprechenden Kommentar(e) welche die Lösung waren, markieren. Merci.
Grüße Uwe
Zitat von @soundinle:
Okay, "lauschen" war wohl nicht das korrekte Wort. Also ist "Destination", wie du sagst, nichts weiter als der
"Adressaufkleber" für den Server, wo er die Datenpackete nach der Entschlüsselung hinschicken soll: An sein
Loopbackinterface, an seine Netzwerkkarte oder woanders hin. Habe ich es jetzt?
yipOkay, "lauschen" war wohl nicht das korrekte Wort. Also ist "Destination", wie du sagst, nichts weiter als der
"Adressaufkleber" für den Server, wo er die Datenpackete nach der Entschlüsselung hinschicken soll: An sein
Loopbackinterface, an seine Netzwerkkarte oder woanders hin. Habe ich es jetzt?
Zitat von @soundinle:
Okay, super, jetzt habe ich das verstanden! Letzte Frage: Nimmt "man" allgemein eher die Loopbackadresse oder die
Netzwerkadresse als Ziel? Gibt es bei einem irgendwelche netzwerktechnischen Vorteile? Das muss ich jetzt nicht verstehen, da reicht jetzt ein "A" oder "B" aus
Entweder oder, ist eigentlich egal...kommt immer auf den Anwendungszweck an.Okay, super, jetzt habe ich das verstanden! Letzte Frage: Nimmt "man" allgemein eher die Loopbackadresse oder die
Netzwerkadresse als Ziel? Gibt es bei einem irgendwelche netzwerktechnischen Vorteile? Das muss ich jetzt nicht verstehen, da reicht jetzt ein "A" oder "B" aus
Ich glaube, mit der "nur Loopbackadresse" kann ich den Zugriff (in VNC und auch in FreeSSHd) so sperren, dass der Server nur Anfragen auf diese akzeptiert und kann somit ungesichterte Verbindungen auf die ungetunnelte Nrtzwerk-IP des Servers besser verbieten, oder?
Ja, aber die Option in VNC ist "eigentlich" nur zu lokalen Testzwecken gedacht. Die Zugriffsbeschränkung regelt man normalerweise mit einer Firewall. Kannst du aber so machen, das Loopback-IF ist ja selber nur auf dem eigentlichen Rechner erreichbar.Und die allerletzte Frage: Ist der Key, den FreeSSHd am Anfang generiert und dann mit PuTTY abgleicht (das ist so die
Standardvariante, bei der man als User nichts weiter machen muss als den generierten Key in PuTTY zu akzeptieren) ausreichend sicher?
Das was zu bei der ersten Verbindung mit dem Server mitgeteilt bekommst(Server-HostKey) ist für deine Überprüfung ob der Server der Antwortet tatsächlich der ist mit dem du dich verbinden möchtest. Wenn nun z.B. ein Angreifer eine Man-In-The-Middle-Attacke starten würde hätte dieser mit seinem Roque-SSH-Server einen anderen HostKey und Putty würde das mit einer Warnung quittieren, weil es die IP-Adresse und den zugehörigen HostKey deines Servers in der Registry speichert.Standardvariante, bei der man als User nichts weiter machen muss als den generierten Key in PuTTY zu akzeptieren) ausreichend sicher?
ich werde dann den Beitrag, der zur Lösung beigetragen hat, markieren (die haben aber alle extrem geholfen!)
merci
Es gibt schon seit längerem hier ein Forumstutorial des Kollegen spacyfreak das dieses Thema recht gut beschreibt:
VPN für Arme - TCP in SSH tunneln mit Putty
VPN für Arme - TCP in SSH tunneln mit Putty