Manchmal brauchen wir Daten über eine Steckdose übertragen zwischen verschiedenen Computern, z. B. einer Telnet-Verbindung, einem Download von FTP-Dateien, einer SQL-Abfrage oder einer anderen Art der Übertragung.
Diese Daten werden also roh durch das Netzwerk übertragen unsicherDies bedeutet, dass sie von jedem Knoten abgefangen werden können, der sich auf dem Pfad zwischen dem Ursprung und dem Ziel befindet, d. h. Robados.
Wir können nicht verhindern, dass diese Daten erfasst werden. Wir können jedoch verhindern, dass sie von Dritten interpretiert und verstanden werden, wodurch die Kommunikation verschlüsselt wird.
SSH ist das Werkzeug, das es uns ermöglicht sichere Verbindungen zwischen Maschinen. Am häufigsten wird eine Remoteverbindung mit einem Befehlsinterpreter hergestellt.
Es bietet jedoch andere Möglichkeiten, wie z. B. das Erstellen verschlüsselte Tunnel zwischen verschiedenen Maschinen.
Angenommen, wir möchten von Host1 zu Host2 telneten:
host1$ telnet host2
Diese Kommunikation ist völlig offen und kann sein abgefangen. Zum Schutz leiten wir einen willkürlich ausgewählten Port (z. B. 5000) auf Host 1 auf Port 23 (Telnet) auf Host 2 um.
Auf diese Weise erhalten wir alle Daten, die an Port 5000 von Host1 gesendet werden, um verschlüsselt durch den Tunnel zu reisen, den SSH über Port 22 von Host2 öffnet, und werden dann zu Port 23 von Host2 umgeleitet, wodurch das endgültige Ziel erreicht wird.
Dazu müssen wir den Benutzernamen und das Passwort von host2 kennen.
Um den Tunnel zu öffnen, schreiben wir:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
Ach ja:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Beide Optionen sind gleichwertig. Um die Telnet-Verbindung herzustellen, verweisen wir nicht mehr auf Host2, sondern auf den auf Host1 ausgewählten Port:
host1$ telnet localhost 5000
Damit machen wir jede Kommunikation sicher, sei es Telnet oder auf andere Weise. Wenn wir etwas mehr untersuchen, werden wir das dank der Kraft von sehen SSH Diese Umleitungen können auch auf dritte Maschinen ausgeführt werden, sodass wir mit einem einzigen Einstiegspunkt sicher von einem gesamten LAN auf ein anderes LAN zugreifen können.
Die Theorie sieht äußerst interessant aus, aber es wäre noch interessanter, wenn wir einen praktischen Fall sehen würden.
Aber die Wahrheit ist, dass ich den Artikel geliebt habe, obwohl ich klein war.
Wenn Sie sich das Wiki ansehen, werden Sie vielleicht inspiriert https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
und das gleiche, aber der autossh Abschnitt https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
Eigentlich alles, was Sie per SSH senden können, sei es Streaming, Verbindungen zum Host. usw. dass Sie sie aus x Gründen verschlüsseln möchten.
und die Sicherheitsregeln
Ich benutze manchmal SSH auf einer sehr einfachen Ebene. Der Standardport ist 22, oder?
Wenn ich das richtig verstehe, ist mein PC Host 1 und derjenige, mit dem ich eine Verbindung herstellen möchte, ist Host 2. Dieser Tunnel würde eine Verbindung zwischen Port 5000 und seinem Port 23 herstellen und dann auf Port 22 landen.
Warum die Gründe, die Ports zu wechseln? Können Sie einen Tunnel mit Port 22 erstellen?
Sehr interessanter Artikel. Wie Nano will ich mehr!
SSH verwendet tatsächlich standardmäßig Port 22 (obwohl dieser geändert werden kann). Dieser Port wird für die eigentliche Kommunikation zwischen den beiden Hosts verwendet. Es ist das, bei dem Sie sicherstellen müssen, dass es geöffnet ist und keine Firewall es abschneidet. Für den Benutzer ist es jedoch völlig transparent. Du kannst es vergessen. In diesem Beispiel erfolgt die Umleitung zwischen den Ports 5000 und 23. Diese beiden sind die einzigen, über die Sie sich Sorgen machen müssen. Der Benutzer sieht, dass alles, was er an Port 5000 seines Hosts sendet, auf 23 des Zielhosts angezeigt wird.
Natürlich kann jeder Benutzer die Ports umleiten, die er für angemessen hält.
Danke für deine Kommentare. Dies ist mein erster Beitrag und Ihre Meinung wird dazu beitragen, den nächsten besser zu machen.
Kann das auch mit VPS gemacht werden?
Ok, das ist mein Fall, PC1 hat Zugriff auf einen Server, aber PC2 stellt keine Verbindung über ssh her. Ich möchte Zugriff auf PC2 haben, aber welchen Port von PC1 leite ich um? Wenn ich eigentlich möchte, dass der Server-Port von PC2 aus erreicht wird und die Pakete PC1 als Quell-IP haben. verstehe ich
Du machst dich verständlich. In diesem Fall benötigen Sie PC1, um einen Port von PC2 auf Port 22 des Servers umzuleiten:
PC2 $ ssh -L 5000: Server: 22 Benutzer PC1 @ PC1
und, diese Verbindung offen zu halten, von einem anderen Terminal aus:
PC2 $ ssh userServer @ localhost -p 5000
und du bist schon drinnen.
Endlich eine funktionale Lösung !! Danke Getafix, du hast mir eine Welt voller Möglichkeiten gegeben !!
Ich bin froh!
Ausgezeichneter Artikel. Willkommen zu DesdeLinux :)
Und was tun, wenn wir 22 blockiert haben? LOL ..
Danke elav.
Wenn Sie Port 22 blockiert haben, mmmm, müssen wir nach einer Alternative suchen, um die XD-Firewall zu hacken
Und das Schlimmste (hypothetisch): dass es vom VPS-Anbieter blockiert wird.
Ich habe vor ein paar Stunden eine Prüfung mit Fragen dazu gemacht 😛
Ich würde das nicht sagen:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Es entspricht der anderen Befehlszeile ... der mit dem -L.
Da -R angibt, dass sich der Port, der für neue Verbindungen geöffnet wird, auf der Remote-Seite befindet, dh auf der Seite Ihres SSH-Servers. Während -L einen Port auf der lokalen Seite öffnet, auf der Clientseite, um neue Verbindungen zu empfangen.
Die Übersetzung der Zeile:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Es wäre ungefähr so: Wenn Sie sich auf Host1 befinden, stellen Sie mit meinem Benutzer userhost22 eine Verbindung zum SSH-Server (Port 2) von Host2 her und leiten Sie die auf dem Remote-Port 5000 von Host2 generierten Verbindungen an Port 23 auf Host1 (meinem Localhost) weiter.
Wenn nicht, korrigiere mich! 😉
-
Andererseits ... wenn ein Server die Eingabe von Verbindungen zu Port 22 blockiert hat, können wir keine Remoteverbindung zum SSH-Server herstellen. was getan werden kann ist; dass vom Server (einem befreundeten Systemadministrator hinter der Firewall des Remote-Host2-Systems) eine Befehlszeile ausgeführt wird:
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f geht in den Hintergrund
-N führt keinen Befehl auf der Fernbedienung aus
nohup verhindert, dass die Ausführung des Befehls beim Abmelden unterbrochen wird
host1 $ ssh userhost2 @ localhost -p 6000
Auf diese Weise generieren wir von Host1 aus eine Verbindung zu localhost (demselben Host1) auf Port 6000, die die Verbindung zu Port 22 des Remote-Systems Host2 weiterleitet, in dem wir uns mit dem Benutzer Host2 anmelden.
Dies würde es ermöglichen (ich habe es nicht getestet, aber es scheint zu funktionieren), sich mit ein wenig Hilfe von innen bei einem von Firewal blockierten SSH-Server anzumelden! 😀
Letzteres habe ich aus einer Erklärung in der Zeitschrift The Geek Stuff gelesen
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
Ihre Veröffentlichung gefällt mir sehr gut. Ich lese sie oft!
Grüße.
Du hast recht. Der Artikel enthält einen Fehler. Weiterleitungen sind nicht gleichwertig. Der Befehl host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 führt die umgekehrte Umleitung durch, dh er leitet den Remote-Port 5000 an den 23 local um, das Gegenteil von dem, was der Befehl mit -L tut.
Danke für die Verbesserung.