14
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?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 225591
Url: https://administrator.de/contentid/225591
Ausgedruckt am: 22.11.2024 um 16: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
4
Hi colinardo,
vielen vielen Dank für deine ausführliche Antwort, sogar mit Bild!
Dass alles, was das Forwarding durchläuft getunnelt wird, hört sich ja schonmal beruhigend an. Dann ist zumindest schonmal alles, was ich da eintrage, verschlüsselt - gut so und sehr beruhigend
Ich muss gestehen, dass ich noch ganz neu in diesem Thema bin, obwohl ich mich natürlich eingelesen habe in die Thematik. Komplett neu war für mich die Info, dass ich auch Ports/Daten an Rechner weiterleiten kann, die "hinter" dem SSH stehen. Könnte man also sagen, dass das, was ich in "PuTTY" unter "Destination" eintrage, eine Anweisung für den Server ist, was er mit den Daten, die am Ende des Tunnels ankommen, machen soll und somit dieses "Destination" eher ein serverseitiges Vorgehen beschreibt und kein Clientseitiges? Weil alles, was ich von PuTTY aus wegschicke ja erstmal im ersten Schritt beim Server ankommt. Würde das bedeuten, dass wenn ich unter "Destination" eine Adresse eintrage, die nicht die Serveradresse ist, die Daten von PuTTY zum SSH-Server verschlüsselt transportiert werden, der Server aber dann merkt, dass er nicht der eigentliche "Empfänger" ist und die Daten dann unverschlüsselt zu dem weiteren Rechner transportiert?
______________________
EDIT: Habe gerade getestet, ob das mit dem Weiterleiten an einen "dritten" Rechner wirklich funktioniert (ich wollte das einfach mal testen *g*). Und was soll ich sagen: Es funktioniert tadellos und ich kann von Rechner A durch den Tunnel zu Rechner B mein VNC auf Rechner C steuern. Was mich glaube ich nur verwirrt ist die Frage, ob die Informationen, die ich in "PuTTY" unter "Destination" eintrage, vom Client oder vom Server "verarbeitet" werden. Da die Auswertung dieser Daten nach dem Herstellen der SSH-Verbindung erfolgt, gehe ich vom Server als Interpreter aus, oder?
vielen vielen Dank für deine ausführliche Antwort, sogar mit Bild!
Dass alles, was das Forwarding durchläuft getunnelt wird, hört sich ja schonmal beruhigend an. Dann ist zumindest schonmal alles, was ich da eintrage, verschlüsselt - gut so und sehr beruhigend
Ich muss gestehen, dass ich noch ganz neu in diesem Thema bin, obwohl ich mich natürlich eingelesen habe in die Thematik. Komplett neu war für mich die Info, dass ich auch Ports/Daten an Rechner weiterleiten kann, die "hinter" dem SSH stehen. Könnte man also sagen, dass das, was ich in "PuTTY" unter "Destination" eintrage, eine Anweisung für den Server ist, was er mit den Daten, die am Ende des Tunnels ankommen, machen soll und somit dieses "Destination" eher ein serverseitiges Vorgehen beschreibt und kein Clientseitiges? Weil alles, was ich von PuTTY aus wegschicke ja erstmal im ersten Schritt beim Server ankommt. Würde das bedeuten, dass wenn ich unter "Destination" eine Adresse eintrage, die nicht die Serveradresse ist, die Daten von PuTTY zum SSH-Server verschlüsselt transportiert werden, der Server aber dann merkt, dass er nicht der eigentliche "Empfänger" ist und die Daten dann unverschlüsselt zu dem weiteren Rechner transportiert?
______________________
EDIT: Habe gerade getestet, ob das mit dem Weiterleiten an einen "dritten" Rechner wirklich funktioniert (ich wollte das einfach mal testen *g*). Und was soll ich sagen: Es funktioniert tadellos und ich kann von Rechner A durch den Tunnel zu Rechner B mein VNC auf Rechner C steuern. Was mich glaube ich nur verwirrt ist die Frage, ob die Informationen, die ich in "PuTTY" unter "Destination" eintrage, vom Client oder vom Server "verarbeitet" werden. Da die Auswertung dieser Daten nach dem Herstellen der SSH-Verbindung erfolgt, gehe ich vom Server als Interpreter aus, oder?
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
3
Okay, ich glaube, ich komme der Sache näher. Danke für deine geduldigen und informativen Erklärungen! In meinem Fall ist es eindeutig der erste Fall (Local): Ich habe im Heimnetz und auch WAN einen Client, der eine Verbindung zum SSH-Server aufbaut, auf dem auch gleich VNC läuft. Verbessere mich, wenn das dann nicht local ist
Im Ausgangspost habe ich ja 2 Bilder angehängt, auf die ich mir noch nicht zu 100 Prozent einen Reim machen kann. Es müsste also in beiden Bildern so sein, dass der Anfangspunkt natürlich mein Client ist und der "Entschlüsselungspunkt" der SSH-Server. Alle Forwards laufen also in Richtung des SSH-Servers. Ich kapiere nur noch nicht den Unterschied zwischen "127.0.0.1:5900" und "192.168.2.194:5900".
Im ersten Fall müsste der Server ja sagen: "Okay, es kommen Daten am Ende des Tunnels an. Ich schicke die Daten an 127.0.0.1 auf Port 5900. Hoppla, das bin ich ja selbst (localhost). Also stelle ich selbst eine Verbindung mit dem VNC-Server her, der auf mir läuft. Deshalb hat mein Admin ja in VNC auch "allow loopback connections" und "only allow loopback connections" angehakt."
Im zweiten Fall sagt der Server dann doch auch, dass am Ende Daten ankommen, die er an die 192.168.2.194 auf Port 5900 schickt. Das ist doch technisch gesehen das gleiche, da der Server doch sowohl 192.168.2.194 als auch 127.0.0.1 ist: Er muss die Daten wiederum an sich selbst schicken. Aber aus irgendeinem Grund ist das dann keine Loopback-Connection (man muss in VNC den Haken bei "only allow loopback connections" rausmachen, damit eine Verbindung klappt --> Folglich in diesem Fall kein Loopback).
Könntest du mir bitte noch erklären, warum das dann so ist? Ich hoffe, man muss jetzt kein studierter Informatiker sein, um das zu verstehen
Im Ausgangspost habe ich ja 2 Bilder angehängt, auf die ich mir noch nicht zu 100 Prozent einen Reim machen kann. Es müsste also in beiden Bildern so sein, dass der Anfangspunkt natürlich mein Client ist und der "Entschlüsselungspunkt" der SSH-Server. Alle Forwards laufen also in Richtung des SSH-Servers. Ich kapiere nur noch nicht den Unterschied zwischen "127.0.0.1:5900" und "192.168.2.194:5900".
Im ersten Fall müsste der Server ja sagen: "Okay, es kommen Daten am Ende des Tunnels an. Ich schicke die Daten an 127.0.0.1 auf Port 5900. Hoppla, das bin ich ja selbst (localhost). Also stelle ich selbst eine Verbindung mit dem VNC-Server her, der auf mir läuft. Deshalb hat mein Admin ja in VNC auch "allow loopback connections" und "only allow loopback connections" angehakt."
Im zweiten Fall sagt der Server dann doch auch, dass am Ende Daten ankommen, die er an die 192.168.2.194 auf Port 5900 schickt. Das ist doch technisch gesehen das gleiche, da der Server doch sowohl 192.168.2.194 als auch 127.0.0.1 ist: Er muss die Daten wiederum an sich selbst schicken. Aber aus irgendeinem Grund ist das dann keine Loopback-Connection (man muss in VNC den Haken bei "only allow loopback connections" rausmachen, damit eine Verbindung klappt --> Folglich in diesem Fall kein Loopback).
Könntest du mir bitte noch erklären, warum das dann so ist? Ich hoffe, man muss jetzt kein studierter Informatiker sein, um das zu verstehen
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
3
Ahh, langsam wird es klar. Du schreibst wirklich sehr verständlich ... und mir reicht es ja, einigermaßen zu wissen, was da abgeht. Ich bereite da drüber ja keine Vorlesung vor, finde das Thema aber hoch spannend Als "Advanced-End-User" haben mir nur die Zusammenhänge etwas gefehlt, die ich so nicht ergooglen konnte. Danke!
Das, was ich unter "Destination" eintrage, sagt dem Server also, wo er genau lauschen soll (wenn alles im Server gescheit eingestellt ist und aktiviert ist). Wenn ich als Destination die Loopback des Servers habe, lauscht dieser dort und die Pakete werden als "Loopback-Pakete" behandelt (man muss Loopback im VNC-Server aktivieren z.B.). 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?
Als "Advanced-End-User" haben mir nur die Zusammenhänge etwas gefehlt, die ich so nicht ergooglen konnte. Danke!Das, was ich unter "Destination" eintrage, sagt dem Server also, wo er genau lauschen soll (wenn alles im Server gescheit eingestellt ist und aktiviert ist). Wenn ich als Destination die Loopback des Servers habe, lauscht dieser dort und die Pakete werden als "Loopback-Pakete" behandelt (man muss Loopback im VNC-Server aktivieren z.B.). 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?
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
2
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?
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?
1
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?
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?
ich werde dann den Beitrag, der zur Lösung beigetragen hat, markieren (die haben aber alle extrem geholfen!)
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?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?
ich werde dann den Beitrag, der zur Lösung beigetragen hat, markieren (die haben aber alle extrem geholfen!)
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 2
Dankeschön für deine tolle Hilfe! Ich hoffe, dass unser Gespräch auch anderen Usern hilft, so wie es mir geholfen hat - Es wurde doch einiges klarer
Auch dir einen guten Rutsch hinüber nach 2014!
Auch dir einen guten Rutsch hinüber nach 2014!
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
1
Dankeschön! Da werde ich mich mal durcharbeiten ... aber erstmal arbeite ich mich durchs Raclette Guten Rutsch!
Guten Rutsch!
