Ibland behöver vi överföra data via ett uttag mellan olika maskiner, såsom en Telnet-anslutning, en FTP-filnedladdning, en SQL-fråga eller någon annan typ av överföring.
Den informationen går rå genom nätverket, så I osäkra, vilket innebär att de kan fångas upp av vilken nod som helst på vägen mellan ursprunget och destinationen, det vill säga stulen.
Vi kan inte förhindra att dessa data fångas in, men vad vi kan förhindra är att de tolkas och förstås av tredje part, vilket krypterar kommunikationen.
SSH är det verktyg som låter oss göra säkra anslutningar mellan maskiner. Den vanligaste användningen är att fjärransluta till en kommandotolk.
Men det erbjuder andra möjligheter, som att skapa krypterade tunnlar mellan olika maskiner.
Antag att vi vill telnet från host1 till host2:
host1$ telnet host2
Denna kommunikation är helt öppen och kan vara skuren. För att skydda det kommer vi att omdirigera en godtyckligt vald port (till exempel 5000) på värd 1 till port 23 (telnet) på värd2.
På detta sätt får vi all information som skickas till port 5000 i värd1 för att resa krypterad genom tunneln som ssh öppnar genom port 22 på värd2 och sedan omdirigeras till port 23 på värd2 och därmed nå sin slutdestination.
För att göra detta måste vi veta användarnamnet och lösenordet för host2.
För att öppna tunneln skriver vi:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
Nåväl:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Båda alternativen är likvärdiga. För att upprätta telnet-anslutningen hänvisar vi inte längre till host2 utan till den port som valts på host1:
host1$ telnet localhost 5000
Med detta gör vi all kommunikation säker, vare sig det är telnet eller annat. Undersöker lite mer kommer vi att se det tack vare kraften i SSH Dessa omdirigeringar kan också göras till tredje maskiner, vilket gör det möjligt för oss att med en enda ingångspunkt kan vi säkert komma åt från ett helt LAN till ett annat LAN.
Teorin ser väldigt intressant ut, men det skulle vara ännu mer intressant om vi såg ett praktiskt fall.
Men sanningen är att även om jag var kort så älskade jag artikeln.
kanske titta på wiki du blir inspirerad https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
och detsamma, men autossh-avsnittet https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
Egentligen, allt du kan skicka med ssh, vare sig det är streaming, anslutningar till värden. etc. att av x anledning vill du kryptera dem.
och säkerhetsreglerna
Jag använder ibland SSH på en mycket grundläggande nivå. Standardporten är 22, eller hur?
Så om jag förstår rätt är min dator värd 1 och den som jag vill ansluta värd2, skulle den här tunneln skapa en anslutning mellan port 5000 och dess port 23 och sedan hamna på port 22?
Varför anledningarna till att byta port? Kan du skapa en tunnel med port 22?
Mycket intressant artikel. Precis som nano är jag kvar och vill ha mer!
SSH använder verkligen port 22 som standard (även om den kan ändras). Denna port är den som den faktiska kommunikationen mellan de två värdarna skulle använda. Det är den du måste se till att den är öppen och ingen brandvägg bryter av den. Men för användaren är det helt transparent. Du kan glömma bort det. I exemplet är omdirigeringen mellan portarna 5000 och 23. Dessa två är de enda du behöver oroa dig för. Användaren ser att allt han skickar till port 5000 för sin värd visas vid målvärdens 23.
Uppenbarligen kan varje användare omdirigera de portar som han anser lämpliga.
Tack för dina kommentarer. Det här är mitt första inlägg och dina åsikter hjälper dig att göra nästa bättre.
Kan det också göras med VPS?
Ok det här är mitt fall, PC1 har tillgång till en server, men PC2 gör inte, båda ansluter via ssh, jag vill ha åtkomst i PC2, men vilken port av PC1 omdirigerar jag? om det egentligen är vad jag vill är att nå serverporten från PC2 och att paketen har PC1 som käll-IP. förstår jag?
Du gör dig själv förstådd. I det här fallet behöver du PC1 för att omdirigera en port av PC2 till port 22 på servern:
PC2 $ ssh -L 5000: Server: 22 användare PC1 @ PC1
och hålla denna anslutning öppen från en annan terminal:
PC2 $ ssh userServer @ localhost -p 5000
och du är redan inne.
Äntligen en funktionell lösning !! Tack Getafix, du har gett mig en värld av möjligheter !!
Jag är glad!
Utmärkt artikel. Välkommen till DesdeLinux ????
Och vad ska vi göra om vi har 22 blockerade? LOL..
Tack elav.
Om du har port 22 blockerad, mmmm, måste vi leta efter ett alternativ för att hacka XD-brandväggen
Och värst av allt (hypotetiskt): att det blockeras av VPS-leverantören.
Jag gjorde precis ett prov för några timmar sedan med frågor om det 😛
Jag skulle inte säga det:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
det motsvarar den andra kommandoraden ... den med -L.
Eftersom -R indikerar att porten som öppnas för nya anslutningar finns på fjärrsidan, det vill säga på sidan av din ssh-server; medan -L öppnar en port på den lokala sidan, på klientsidan för att ta emot nya anslutningar.
Översättningen av linjen:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Det skulle vara ungefär så här: Var på host1, anslut till ssh-servern (port 22) på host2 med min användare userhost2 och vidarebefordra anslutningarna som genereras på fjärrport 5000 på host2 till port 23 på host1 (min localhost)
Om inte, korrigera mig! 😉
-
Å andra sidan ... om en server har blockerat inmatningen av anslutningar till port 22, det vill säga, kan vi inte ansluta fjärrstyrt till ssh-servern; vad som kan göras är; att från servern (en vän sysadmin bakom brandväggen i fjärrvärden2-systemet) körs en kommandorad:
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f går till bakgrunden
-N kör inget kommando på fjärrkontrollen
nohup förhindrar att körningen av kommandot avbryts vid utloggning
host1 $ ssh userhost2 @ localhost -p 6000
På detta sätt genererar vi från värd1 en anslutning till localhost (samma värd1) på port 6000 som vidarebefordrar anslutningen till port 22 på fjärrsystemets värd2, där vi loggar in med användarvärden2.
Detta skulle tillåta (jag testade inte det, men det låter som om det fungerar) att logga in på en ssh-server blockerad av brandvägg med lite hjälp inifrån! 😀
Det senare läste jag från en förklaring i tidningen The Geek Stuff
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
Jag gillar verkligen din publikation; Jag läser dem ofta!
Hälsningar.
Du har rätt. Det finns ett fel i artikeln. Omdirigeringar är inte likvärdiga. Kommandot host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 utför omvänd omdirigering, det vill säga, det omdirigerar fjärrporten 5000 till 23 local, motsatsen till vad kommandot med -L gör.
Tack för rättelsen.