Nogle gange har vi brug for det overføre data gennem et stik mellem forskellige maskiner, såsom en Telnet-forbindelse, en FTP-filoverførsel, en SQL-forespørgsel eller enhver anden form for transmission.
Disse data rejser rå gennem netværket, så jeg usikker, hvilket betyder, at de kunne opfanges af en hvilken som helst knude, der er på stien mellem oprindelsen og destinationen, dvs. stjålet.
Vi kan ikke forhindre, at disse data fanges, men hvad vi kan forhindre, er at de fortolkes og forstås af tredjeparter, krypterer kommunikationen.
SSH er det værktøj, der giver os mulighed for at gøre sikre forbindelser mellem maskiner. Dens mest almindelige anvendelse er at oprette forbindelse eksternt til en kommandotolk.
Det giver dog andre muligheder, såsom at skabe krypterede tunneler mellem forskellige maskiner.
Antag, at vi vil telnet fra vært1 til vært2:
host1$ telnet host2
Denne kommunikation er helt åben og kan være gennemskåret. For at beskytte det omdirigerer vi en vilkårligt valgt port (for eksempel 5000) på vært 1 til port 23 (telnet) på host2.
På denne måde får vi alle data sendt til port 5000 i vært1 for at rejse krypteret gennem tunnelen, som ssh åbner gennem port 22 på vært2 og derefter omdirigeres til havn 23 på vært2 og dermed nå sin endelige destination.
For at gøre dette skal vi kende host2's brugernavn og adgangskode.
For at åbne tunnelen skriver vi:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
O brønd:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Begge muligheder er ækvivalente. For at etablere telnetforbindelsen henviser vi ikke længere til host2 men til den valgte port på host1:
host1$ telnet localhost 5000
Med dette gør vi enhver kommunikation sikker, det være sig telnet eller på anden måde. Undersøger lidt mere vil vi se det takket være kraften i SSH Disse omdirigeringer kan også foretages til tredje maskiner, hvilket giver os mulighed for, at vi med et enkelt indgangspunkt sikkert kunne få adgang fra et helt LAN til et andet LAN.
Teorien ser meget interessant ud, men det ville være endnu mere, hvis vi så en praktisk sag.
Men sandheden er, at selvom jeg var kort, elskede jeg artiklen.
måske ser du på wiki, du bliver inspireret https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
og det samme, men autossh sektionen https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
Faktisk kan alt, hvad du kan sende med ssh, det være sig streaming, forbindelser til værten. etc. at du af x-grund vil kryptere dem.
og sikkerhedsreglerne
Jeg bruger nogle gange SSH på et meget grundlæggende niveau. Standardporten er 22, ikke?
Så hvis jeg forstår korrekt, er min pc vært 1, og den, jeg vil oprette forbindelse til, er host2, ville denne tunnel skabe en forbindelse mellem port 5000 og dens port 23 og derefter ende på port 22?
Hvorfor årsagerne til at skifte havn? Kan du oprette en tunnel med port 22?
Meget interessant artikel. Ligesom nano er jeg tilbage og ønsker mere!
SSH bruger faktisk port 22 som standard (selvom den kan ændres). Denne port er den, der ville blive brugt af den faktiske kommunikation mellem de to værter. Det er den, du skal sørge for, at den er åben, og ingen firewall afbryder den. Men for brugeren er det helt gennemsigtigt. Du kan glemme det. I eksemplet er omdirigering mellem porte 5000 og 23. Disse to er de eneste, du skal bekymre dig om. Brugeren vil se, at alt, hvad han sender til havnens 5000 port, vises kl 23 for destinationsværten.
Det er klart, at hver bruger kan omdirigere de porte, han finder passende.
Tak for dine kommentarer. Dette er mit første indlæg, og dine meninger hjælper med at gøre det næste bedre.
Kan det også gøres med VPS?
Ok dette er min sag, PC1 har adgang til en server, men PC2 forbinder ikke, begge forbinder med ssh, jeg vil have adgang i PC2, men hvilken port PC1 omdirigerer jeg? hvis det, jeg faktisk vil, er at nå serverporten fra PC2, og at pakkerne har PC1 som kilde-IP. forstår jeg det?
Du gør dig forstået. I dette tilfælde har du brug for PC1 for at omdirigere en PC2-port til port 22 på serveren:
PC2 $ ssh -L 5000: Server: 22 bruger PC1 @ PC1
og ved at holde denne forbindelse åben fra en anden terminal:
PC2 $ ssh userServer @ localhost -p 5000
og du er allerede inde.
Endelig en funktionel løsning !! Tak Getafix, du har givet mig en verden af muligheder !!
Jeg er glad!
Fremragende artikel. velkommen til DesdeLinux ????
Og hvad skal vi gøre, hvis vi har 22 blokeret? LOL ..
Tak elav.
Hvis du har blokeret port 22, mmmm, bliver vi nødt til at kigge efter et alternativ til at hacke XD-firewallen
Og værst af alt (hypotetisk): at det er blokeret af VPS-udbyderen.
Jeg har lige lavet en eksamen for et par timer siden med spørgsmål om det 😛
Jeg vil ikke sige det:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
det svarer til den anden kommandolinje ... den med -L.
Da -R indikerer, at porten, der åbnes for nye forbindelser, er på den eksterne side, det vil sige på siden af din ssh-server; mens -L åbner en port på den lokale side, på klientsiden for at modtage nye forbindelser.
Oversættelsen af linjen:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Det ville være noget som dette: At være på host1, oprette forbindelse til ssh-serveren (port 22) på host2 med min bruger userhost2 og videresende de forbindelser, der genereres på fjernport 5000 på host2 til port 23 på host1 (min lokale vært)
Hvis ikke, skal du rette mig! 😉
-
På den anden side ... hvis en server har blokeret adgangen til forbindelser til port 22, det vil sige, kan vi ikke oprette forbindelse eksternt til ssh-serveren; hvad der kan gøres er; at der fra serveren (en ven sysadmin bag firewallen til det eksterne host2-system) udføres en kommandolinje:
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f går til baggrunden
-N udfører ikke nogen kommando på fjernbetjeningen
nohup forhindrer udførelsen af kommandoen i at blive afbrudt, når du logger ud
host1 $ ssh userhost2 @ localhost -p 6000
På denne måde genererer vi fra vært1 en forbindelse til localhost (den samme vært1) på port 6000, der videresender forbindelsen til port 22 på den eksterne systemhost2, hvor vi logger ind med brugerhost2.
Dette ville tillade (jeg testede det ikke, men det lyder som om det fungerer) at logge ind på en ssh-server blokeret af firewal med lidt hjælp indefra! 😀
Sidstnævnte læste jeg fra en forklaring i The Geek Stuff magazine
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
Jeg kan virkelig godt lide din publikation; Jeg læser dem ofte!
Greetings.
Du har ret. Der er en fejl i artiklen. Omdirigeringer er ikke ækvivalente. Kommandoværten1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 udfører den omvendte omdirigering, det vil sige, den omdirigerer fjernporten 5000 til de 23 lokale, det modsatte af hvad kommandoen med -L gør.
Tak for rettelsen.