Noen ganger trenger vi overføre data gjennom en stikkontakt mellom forskjellige maskiner, for eksempel en Telnet-tilkobling, en FTP-filnedlasting, et SQL-spørsmål eller en hvilken som helst annen form for overføring.
At dataene går rå gjennom nettverket, så usikker, som betyr at de kan bli snappet opp av en hvilken som helst node som er på banen mellom opprinnelsen og destinasjonen, det vil si stjålet.
Vi kan ikke forhindre at disse dataene blir fanget, men det vi kan forhindre er at de tolkes og forstås av tredjeparter, krypterer kommunikasjonen.
SSH er verktøyet som lar oss gjøre sikre forbindelser mellom maskiner. Den vanligste bruken er å koble eksternt til en kommandotolk.
Det gir imidlertid andre muligheter, for eksempel å lage krypterte tunneler mellom forskjellige maskiner.
Anta at vi vil telnet fra host1 til host2:
host1$ telnet host2
Denne kommunikasjonen er helt åpen og kan være kåret. For å beskytte den, vil vi omdirigere en vilkårlig valgt port (for eksempel 5000) på vert 1 til port 23 (telnet) til host2.
På denne måten vil vi få alle dataene sendt til port 5000 på host1 for å reise kryptert gjennom tunnelen som ssh åpner gjennom port 22 på host2 og deretter blir omdirigert til port 23 på host2, og dermed nå sitt endelige mål.
For å gjøre dette må vi vite brukernavnet og passordet til host2.
For å åpne tunnelen skriver vi:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
O brønn:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Begge alternativene er likeverdige. For å etablere telnetforbindelsen, refererer vi ikke lenger til host2, men til den valgte porten på host1:
host1$ telnet localhost 5000
Med dette gjør vi enhver kommunikasjon sikker, det være seg telnet eller på annen måte. Undersøke litt mer vil vi se det takket være kraften i SSH disse omdirigeringene kan også utføres til tredje maskiner, noe som vil tillate oss at vi med et enkelt inngangspunkt trygt kunne få tilgang fra et helt LAN til et annet LAN.
15 kommentarer, legg igjen dine
Teorien ser ekstremt interessant ut, men det ville være enda mer hvis vi så en praktisk sak.
Men sannheten er at selv om jeg var kort, elsket jeg artikkelen.
kanskje ser på wiki du blir inspirert https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
og det samme, men autossh-delen https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
Egentlig alt du kan sende med ssh, det være seg streaming, tilkoblinger til verten. etc. at du av x grunn vil kryptere dem.
og sikkerhetsreglene
Noen ganger bruker jeg SSH på et veldig grunnleggende nivå. Standardporten er 22, ikke sant?
Så hvis jeg forstår riktig, er datamaskinen min vert 1 og den jeg vil koble til er host2, vil denne tunnelen skape en forbindelse mellom port 5000 og port 23, og deretter havne på port 22?
Hvorfor årsakene til at du bytter porter? Kan du lage en tunnel med port 22?
Veldig interessant artikkel. Som nano, er jeg igjen og vil ha mer!
SSH bruker faktisk port 22 som standard (selv om den kan endres). Denne porten er den som den faktiske kommunikasjonen mellom de to vertene vil bruke. Det er den du må sørge for at den er åpen og ingen brannmur kutter den av. Men for brukeren er det helt gjennomsiktig. Du kan glemme ham. I eksemplet er viderekoblingen mellom porter 5000 og 23. Disse to er de eneste du trenger å bekymre deg for. Brukeren vil se at alt han sender til port 5000 til verten vises på 23 av destinasjonsverten.
Åpenbart kan hver bruker omdirigere portene han anser hensiktsmessig.
Takk for kommentarene dine. Dette er mitt første innlegg, og dine meninger vil bidra til å gjøre det neste bedre.
Kan det også gjøres med VPS?
Ok dette er mitt tilfelle, PC1 har tilgang til en server, men PC2 kobler ikke, begge kobler med ssh, jeg vil ha tilgang i PC2, men hvilken port av PC1 omdirigerer jeg? hvis egentlig det jeg vil er å nå serverporten fra PC2 og at pakkene har PC1 som kilde-IP. forstår jeg?
Du gjør deg forstått. I dette tilfellet trenger du PC1 for å omdirigere en PC2-port til port 22 på serveren:
PC2 $ ssh -L 5000: Server: 22 bruker PC1 @ PC1
og holder denne forbindelsen åpen fra en annen terminal:
PC2 $ ssh userServer @ localhost -p 5000
og du er allerede inne.
Endelig en funksjonell løsning !! Takk Getafix, du har gitt meg en verden av muligheter !!
Jeg er glad!
Utmerket artikkel. Velkommen til DesdeLinux 😀
Og hva skal jeg gjøre hvis vi har 22 blokkerte? LOL ..
Takk elav.
Hvis du har blokkert port 22, mmmm, må vi se etter et alternativ for å hacke XD-brannmuren
Og verst av alt (hypotetisk): at den er blokkert av VPS-leverandøren.
Jeg gjorde nettopp en eksamen for noen timer siden med spørsmål om det 😛
Jeg vil ikke si det:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
det tilsvarer den andre kommandolinjen ... den med -L.
Siden -R indikerer at porten som åpnes for nye tilkoblinger, er på den eksterne siden, det vil si på siden av ssh-serveren din; mens -L åpner en port på den lokale siden, på klientsiden for å motta nye forbindelser.
Oversettelsen av linjen:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Det ville være noe sånt som dette: Å være på host1, koble til ssh-serveren (port 22) på host2 med brukerbrukerhost2 og videresend tilkoblingene som genereres på ekstern port 5000 på host2 til port 23 på host1 (min lokale vert)
Hvis ikke, rett meg! 😉
-
På den annen side ... hvis en server har blokkert oppføringen av tilkoblinger til port 22, det vil si, kan vi ikke koble eksternt til ssh-serveren; hva som kan gjøres er; at fra serveren (en venn sysadmin bak brannmuren til det eksterne host2-systemet) kjøres en kommandolinje:
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f går til bakgrunn
-N utfører ikke noen kommando på fjernkontrollen
nohup forhindrer at utførelsen av kommandoen blir avbrutt når du logger ut
host1 $ ssh userhost2 @ localhost -p 6000
På denne måten genererer vi fra vert1 en tilkobling til localhost (samme vert1) på port 6000 som vil videresende forbindelsen til port 22 på den eksterne systemhost2, der vi vil logge på med brukerhost2.
Dette ville tillate (jeg prøvde ikke det, men det høres ut som det fungerer) å logge på en ssh-server blokkert av brannmur med litt hjelp fra innsiden! 😀
Det siste leste jeg fra en forklaring laget i magasinet The Geek Stuff
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
Jeg liker publikasjonen din; Jeg leser dem ofte!
Hilsener.
Du har rett. Det er en feil i artikkelen. Viderekoblinger er ikke likeverdige. Kommandovært1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 utfører omvendt omdirigering, det vil si at den omdirigerer port 5000 til 23 lokale, det motsatte av hva kommandoen med -L gjør.
Takk for rettelsen.