Néha szükségünk van rá adatokat továbbít egy aljzaton keresztül különböző gépek között, például Telnet-kapcsolat, FTP-fájlletöltés, SQL-lekérdezés vagy bármilyen más típusú átvitel.
Ez az adat nyersen halad a hálózaton keresztül, tehát azt bizonytalan, ami azt jelenti, hogy bármelyik csomópont elfoghatja őket, amely az origó és a cél között van, vagyis lopott.
Nem akadályozhatjuk meg ezen adatok rögzítését, de azt megakadályozhatjuk, hogy azokat harmadik felek értelmezzék és megértsék, titkosítva a kommunikációt.
SSH az az eszköz, amely lehetővé teszi számunkra biztonságos kapcsolatok gépek között. Leggyakoribb felhasználása a távoli csatlakozás egy parancsértelmezőhöz.
Ez azonban más lehetőségeket is kínál, például az alkotást titkosított alagutak különböző gépek között.
Tegyük fel, hogy a host1-től a host2-ig akarunk telnetezni:
host1$ telnet host2
Ez a kommunikáció teljesen nyitott és lehet metszett. Védelme érdekében átirányítunk egy tetszőlegesen kiválasztott portot (például 5000) az 1. hoszton a 23. hoszt 2-as (telnet) portjára.
Ily módon az összes adatot elküldjük a host5000 1-es portjába, hogy titkosítva haladjunk az alagúton keresztül, amelyen az ssh megnyílik a host22 2-es portján keresztül, majd átirányítjuk a host23-es 2-as portjába, így elérjük a végcélját.
Ehhez tudnunk kell a host2 felhasználónevét és jelszavát.
Az alagút megnyitásához írjuk:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
Hát:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Mindkét lehetőség egyenértékű. A telnet kapcsolat létrehozásához már nem a host2-re, hanem a host1 kiválasztott portjára hivatkozunk:
host1$ telnet localhost 5000
Ezzel bármilyen kommunikációt biztonságossá teszünk, legyen az telnet vagy más. Kicsit többet vizsgálva látni fogjuk, hogy a SSH ezek az átirányítások harmadik gépekre is végrehajthatók, ami lehetővé tenné számunkra, hogy egyetlen belépési ponttal biztonságosan hozzáférhetnénk egy teljes LAN-tól egy másik LAN-hoz.
Az elmélet rendkívül érdekesnek tűnik, de még inkább így lenne, ha gyakorlati esetet látnánk.
De az az igazság, hogy bár alacsony voltam, szerettem a cikket.
talán megnézi a wikit, amely inspirálódik https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
és ugyanaz, de az autossh szakasz https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
Valójában bármit elküldhet ssh-vel, legyen az streaming, kapcsolat a gazdagéppel. stb. hogy x okból szeretné titkosítani őket.
és a securecrt szabályokat
Az SSH-t néha nagyon alap szinten használom. Az alapértelmezett port 22, igaz?
Tehát, ha jól értem, a számítógépem az 1. gazdagép, és amihez csatlakozni szeretnék, az a host2, ez az alagút kapcsolatot teremtene az 5000-es és a 23-as port között, majd a 22-es portra kerülne?
Miért érdemes a portot váltani? Tudna létrehozni egy alagutat a 22-es porttal?
Nagyon érdekes cikk. Mint a nanó, én is többet akarok!
Az SSH valóban a 22-es portot használja alapértelmezés szerint (bár változtatható). Ezt a portot használja a két gazdagép közötti tényleges kommunikáció. Ez az, amelyet meg kell győződnie arról, hogy nyitva van, és egyetlen tűzfal sem vágja le. De a felhasználó számára ez teljesen átlátszó. Megfeledkezhet róla. A példában az átirányítás az 5000 és a 23-as portok között zajlik. Csak ezen kettő miatt kell aggódnia. A felhasználó látni fogja, hogy minden, amit a hostjának az 5000-es portjához küld, a célállomás 23-nál jelenik meg.
Nyilvánvaló, hogy minden felhasználó átirányíthatja az általa megfelelőnek tartott portokat.
Köszönöm a megjegyzéseket. Ez az első hozzászólásom, és a véleményetek segítenek abban, hogy a következő jobb legyen.
Meg lehet ezt tenni VPS-sel is?
Ok, ez az én esetem, a PC1 hozzáfér egy szerverhez, de a PC2 nem, mindkettő ssh-vel csatlakozik, szeretnék hozzáférni a PC2-hez, de a PC1 melyik portját átirányítom? ha valójában azt akarom elérni a szerver portot a PC2-ből, és hogy a csomagok forrás-IP-jének a PC1 van. értem?
Megértetted magaddal. Ebben az esetben a PC1-re van szükség, hogy átirányítsa a PC2 portját a szerver 22. portjába:
PC2 $ ssh -L 5000: Szerver: 22 felhasználó PC1 @ PC1
és nyitva tartva ezt a kapcsolatot egy másik terminálról:
PC2 $ ssh userServer @ localhost -p 5000
és máris bent vagy.
Végül egy funkcionális megoldás !! Köszönöm Getafix, a lehetőségek világát adtad nekem !!
Örülök!
Excelente artículo. Bienvenido a DesdeLinux ????
És mit tegyünk, ha 22 blokkolva van? LOL ..
Köszi elav.
Ha blokkoltad a 22-es portot, mmmm, akkor alternatívát kell keresnünk az XD tűzfal feltörésére
És ami a legrosszabb (hipotetikus): hogy a VPS szolgáltató blokkolja.
Néhány órával ezelőtt csináltam egy vizsgát azzal kapcsolatos kérdésekkel 😛
Nem mondanám, hogy:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
ekvivalens a másik parancssorral ... -vel.
Mivel az -R azt jelzi, hogy az új kapcsolatok számára megnyitott port a távoli oldalon van, vagyis az ssh szerver oldalán; míg a -L megnyit egy portot a Helyi oldalon, az ügyfél oldalon új kapcsolatok fogadásához.
A sor fordítása:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Valami ilyesmi lenne: Ha a host1-en van, csatlakozzon a host22 ssh szerveréhez (2. port) a felhasználói userhost2 felhasználóimmal, és továbbítsa a host5000 távoli 2-es portján létrehozott kapcsolatokat a host23 (my localhost) 1. portjába.
Ha nem, javíts ki! 😉
-
Másrészt ... ha egy szerver blokkolta a 22. porthoz való kapcsolatok beírását, vagyis nem tudunk távolról csatlakozni az ssh szerverhez; mit lehet tenni, az; hogy a kiszolgálóról (egy barát sysadmin a távoli host2 rendszer tűzfala mögött) egy parancssor kerül végrehajtásra:
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f háttérbe kerül
-N nem hajt végre semmilyen parancsot a távvezérlőn
A nohup megakadályozza a parancs végrehajtásának megszakítását a kijelentkezéskor
host1 $ ssh userhost2 @ localhost -p 6000
Ily módon a host1-től létrehozunk egy kapcsolatot a localhost-hoz (ugyanaz a host1) a 6000-es porton, amely továbbítja a kapcsolatot a távoli rendszer host22 2-es portjához, amelyben bejelentkezünk a felhasználói host2-vel.
Ez lehetővé tenné (nem teszteltem, de úgy hangzik, hogy működik) egy belső segítséggel bejelentkezni egy tűz által blokkolt ssh szerverre! 😀
Ez utóbbit a The Geek Stuff magazinban tett magyarázatból olvastam
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
Nagyon tetszik a kiadványod; Gyakran olvasom őket!
Üdvözlet.
Igazad van. Hiba történt a cikkben. Az átirányítások nem egyenértékűek. A host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 parancs fordított átirányítást hajt végre, vagyis átirányítja az 5000 távoli portot a 23 helyi felé, ellentétben azzal, amit a -L parancs végrehajt.
Köszönöm a javítást.