Omdiriger porter over SSH

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.


Innholdet i artikkelen følger våre prinsipper for redaksjonell etikk. Klikk på for å rapportere en feil her.

15 kommentarer, legg igjen dine

Legg igjen kommentaren

Din e-postadresse vil ikke bli publisert.

*

*

  1. Ansvarlig for dataene: Miguel Ángel Gatón
  2. Formålet med dataene: Kontroller SPAM, kommentaradministrasjon.
  3. Legitimering: Ditt samtykke
  4. Kommunikasjon av dataene: Dataene vil ikke bli kommunisert til tredjeparter bortsett fra ved juridisk forpliktelse.
  5. Datalagring: Database vert for Occentus Networks (EU)
  6. Rettigheter: Når som helst kan du begrense, gjenopprette og slette informasjonen din.

  1.   nano sa

    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.

    1.    som sa

      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

  2.   Tesla sa

    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!

    1.    Getafix sa

      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.

  3.   eliotime3000. sa

    Kan det også gjøres med VPS?

  4.   dhunter sa

    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?

    1.    Getafix sa

      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.

      1.    dhunter sa

        Endelig en funksjonell løsning !! Takk Getafix, du har gitt meg en verden av muligheter !!

        1.    Getafix sa

          Jeg er glad!

  5.   elav sa

    Utmerket artikkel. Velkommen til DesdeLinux 😀

    Og hva skal jeg gjøre hvis vi har 22 blokkerte? LOL ..

    1.    Getafix sa

      Takk elav.
      Hvis du har blokkert port 22, mmmm, må vi se etter et alternativ for å hacke XD-brannmuren

    2.    eliotime3000. sa

      Og verst av alt (hypotetisk): at den er blokkert av VPS-leverandøren.

  6.   IGA sa

    Jeg gjorde nettopp en eksamen for noen timer siden med spørsmål om det 😛

  7.   Mario sa

    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.

    1.    Getafix sa

      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.

bool (sant)