Soms hebben we nodig gegevens verzenden via een stopcontact tussen verschillende machines, zoals een Telnet-verbinding, het downloaden van een FTP-bestand, een SQL-query of een ander type overdracht.
Die gegevens reizen onbewerkt door het netwerk, dus onzeker, wat betekent dat ze kunnen worden onderschept door elk knooppunt dat zich op het pad tussen de oorsprong en de bestemming bevindt, dat wil zeggen, gestolen.
We kunnen niet voorkomen dat deze gegevens worden vastgelegd, maar wat we kunnen voorkomen, is dat deze worden geïnterpreteerd en begrepen door derden, waardoor de communicatie wordt versleuteld.
SSH is de tool waarmee we kunnen doen beveiligde verbindingen tussen machines. Het meest gebruikelijke gebruik is om op afstand verbinding te maken met een opdrachtinterpreter.
Het biedt echter andere mogelijkheden, zoals creëren versleutelde tunnels tussen verschillende machines.
Stel dat we willen telnet van host1 naar host2:
host1$ telnet host2
Deze communicatie is volledig open en kan worden onderschept. Om het te beschermen, zullen we een willekeurig gekozen poort (bijvoorbeeld 5000) op host 1 omleiden naar poort 23 (telnet) op host2.
Op deze manier krijgen we alle gegevens die naar poort 5000 van host1 worden gestuurd om versleuteld door de tunnel te reizen die ssh opent via poort 22 van host2 en vervolgens worden omgeleid naar poort 23 van host2, en zo hun eindbestemming bereiken.
Om dit te doen, hebben we de gebruikersnaam en het wachtwoord van host2 nodig.
Om de tunnel te openen schrijven we:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
O goed:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Beide opties zijn gelijkwaardig. Om de telnet-verbinding tot stand te brengen, verwijzen we niet langer naar host2 maar naar de gekozen poort op host1:
host1$ telnet localhost 5000
Hiermee maken we elke communicatie veilig, of het nu telnet is of anderszins. Als we nog wat meer onderzoeken, zullen we dat zien dankzij de kracht van SSH Deze omleidingen kunnen ook worden gemaakt naar derde machines, waardoor we met een enkel toegangspunt veilig toegang kunnen krijgen van een heel LAN naar een ander LAN.
De theorie ziet er buitengewoon interessant uit, maar het zou des te meer zijn als we een praktijkgeval zouden zien.
Maar de waarheid is dat ik, hoewel ik klein was, van het artikel hield.
misschien als je naar de wiki kijkt, raak je geïnspireerd https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
en hetzelfde, maar de autossh-sectie https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
Eigenlijk alles wat u via ssh kunt verzenden, of het nu gaat om streaming, verbindingen met de host. enzovoort. dat je ze om x reden wilt versleutelen.
en de securecrt-regels
Ik gebruik SSH soms op een heel basaal niveau. De standaardpoort is 22, toch?
Dus als ik het goed begrijp, is mijn pc host 1 en degene die ik wil verbinden met host2, zou deze tunnel een verbinding tot stand brengen tussen poort 5000 en zijn poort 23, en dan op poort 22 eindigen?
Waarom de redenen om van poort te wisselen? Kun jij een tunnel maken met poort 22?
Heel interessant artikel. Net als nano wil ik meer!
SSH gebruikt inderdaad standaard poort 22 (hoewel dit kan worden gewijzigd). Deze poort is degene die zou worden gebruikt door de feitelijke communicatie tussen de twee hosts. Het is degene die u moet controleren of het open is en dat geen firewall het afsnijdt. Maar voor de gebruiker is het volledig transparant. Je kunt hem vergeten. In het voorbeeld is de omleiding tussen poort 5000 en 23. Die twee zijn de enige waar u zich zorgen over hoeft te maken. De gebruiker zal zien dat alles wat hij naar poort 5000 van zijn host verzendt, verschijnt op 23 van de bestemmingshost.
Het is duidelijk dat elke gebruiker de poorten kan omleiden die hij geschikt acht.
Dank u voor uw reacties. Dit is mijn eerste post en jouw mening zal helpen om de volgende beter te maken.
Kan dat ook met VPS?
Ok dit is mijn geval, PC1 heeft toegang tot een server, maar PC2 niet, beide maken verbinding via SSH, ik wil toegang hebben in PC2, maar welke poort van PC1 moet ik omleiden? als eigenlijk wat ik wil de serverhaven van PC2 is en dat de pakketten PC1 als hun bron-IP hebben. begrijp ik
Je maakt jezelf verstaanbaar. In dit geval hebt u PC1 nodig om een poort van PC2 om te leiden naar poort 22 van de server:
PC2 $ ssh -L 5000: Server: 22 gebruiker PC1 @ PC1
en, deze verbinding openhouden, vanaf een andere terminal:
PC2 $ ssh userServer @ localhost -p 5000
en je bent al binnen.
Eindelijk een functionele oplossing !! Bedankt Getafix, je hebt me een wereld aan mogelijkheden gegeven !!
Ik ben er blij om!
Uitstekend artikel. welkom bij DesdeLinux ????
En wat te doen als we er 22 hebben geblokkeerd? LOL..
Bedankt elav.
Als je poort 22 geblokkeerd hebt, mmmm, zullen we op zoek moeten gaan naar een alternatief om de XD-firewall te hacken
En het ergste van alles (hypothetisch): dat het wordt geblokkeerd door de VPS-provider.
Ik heb net een paar uur geleden een examen gedaan met daarover vragen 😛
Dat zou ik niet zeggen:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
het is gelijk aan de andere opdrachtregel ... die met de -L.
Aangezien -R aangeeft dat de poort die wordt geopend voor nieuwe verbindingen zich aan de externe kant bevindt, dat wil zeggen aan de kant van uw ssh-server; terwijl -L een poort opent aan de lokale kant, aan de clientkant om nieuwe verbindingen te ontvangen.
De vertaling van de regel:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Het zou ongeveer zo zijn: als je op host1 bent, maak verbinding met de ssh-server (poort 22) van host2 met mijn gebruiker userhost2 en stuur de verbindingen die zijn gegenereerd op externe poort 5000 van host2 door naar poort 23 op host1 (mijn localhost)
Zo niet, corrigeer me dan! 😉
-
Aan de andere kant ... als een server de toegang van verbindingen naar poort 22 heeft geblokkeerd, dat wil zeggen, we kunnen geen externe verbinding maken met de ssh-server; wat kan worden gedaan is; dat vanaf de server (een vriend sysadmin achter de firewall van het remote host2-systeem) een opdrachtregel wordt uitgevoerd:
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f gaat naar de achtergrond
-N voert geen enkele opdracht uit op de afstandsbediening
nohup voorkomt dat de uitvoering van de opdracht wordt onderbroken bij het uitloggen
host1 $ ssh userhost2 @ localhost -p 6000
Op deze manier genereren we vanaf host1 een verbinding met localhost (dezelfde host1) op poort 6000 die de verbinding doorstuurt naar poort 22 van de externe systeemhost2, waar we zullen inloggen met de gebruiker host2.
Dit zou het mogelijk maken (ik heb het niet getest, maar het klinkt alsof het werkt) om in te loggen op een ssh-server die door firewal wordt geblokkeerd met een beetje hulp van binnenuit! 😀
Dat laatste las ik uit een uitleg in het tijdschrift The Geek Stuff
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
Ik vind je publicatie echt leuk; Ik heb ze vaak gelezen!
Groeten.
Je hebt gelijk. Er zit een fout in het artikel. Omleidingen zijn niet gelijkwaardig. Het commando host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 voert de omgekeerde omleiding uit, dat wil zeggen dat het de externe poort 5000 omleidt naar de lokale 23, het tegenovergestelde van wat het commando met -L doet.
Bedankt voor de correctie.