Czasami potrzebujemy przesyłać dane przez gniazdo między różnymi komputerami, na przykład połączenie Telnet, pobieranie pliku FTP, zapytanie SQL lub dowolny inny rodzaj transmisji.
Te dane są przesyłane nieprzetworzone przez sieć, więc niebezpieczny, co oznacza, że mogą zostać przechwycone przez dowolny węzeł znajdujący się na ścieżce między początkiem a miejscem docelowym, czyli skradziony.
Nie możemy zapobiec przechwytywaniu tych danych, ale możemy zapobiec ich interpretacji i zrozumieniu przez osoby trzecie, szyfrując komunikację.
SSH jest narzędziem, które nam na to pozwala bezpieczne połączenia między maszynami. Jego najczęstszym zastosowaniem jest zdalne łączenie się z interpretatorem poleceń.
Oferuje jednak inne możliwości, takie jak tworzenie zaszyfrowane tunele między różnymi maszynami.
Załóżmy, że chcemy telnetować się z hosta1 do hosta2:
host1$ telnet host2
Ta komunikacja jest całkowicie otwarta i może być przechwycony. Aby go zabezpieczyć, przekierujemy arbitralnie wybrany port (na przykład 5000) na hoście 1 do portu 23 (telnet) na hoście 2.
W ten sposób otrzymamy wszystkie dane wysłane do portu 5000 hosta host1, aby podróżować w postaci zaszyfrowanej przez tunel, który ssh otwiera przez port 22 hosta 2, a następnie zostaną przekierowane do portu 23 hosta 2, docierając w ten sposób do miejsca docelowego.
Aby to zrobić, musimy znać nazwę użytkownika i hasło hosta2.
Aby otworzyć tunel piszemy:
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
No cóż:
host1$ ssh -L 5000:host2:23 usuariohost2@host2
Obie opcje są równoważne. Aby ustanowić połączenie telnet, nie odnosimy się już do hosta2, ale do portu wybranego na hoście1:
host1$ telnet localhost 5000
Dzięki temu zapewniamy bezpieczeństwo każdej komunikacji, czy to telnet, czy w inny sposób. Badając trochę więcej, przekonamy się, że dzięki sile SSH te przekierowania mogą być również przeprowadzane na maszyny trzecie, co pozwoliłoby nam na bezpieczny dostęp z całej sieci LAN do innej za pomocą jednego punktu wejścia.
Teoria wygląda niezwykle interesująco, ale byłoby jeszcze bardziej, gdybyśmy zobaczyli praktyczny przypadek.
Ale prawda jest taka, że chociaż byłem krótki, bardzo mi się podobał ten artykuł.
może patrząc na wiki, która Cię inspiruje https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
i to samo, ale sekcja autossh https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
Właściwie wszystko, co możesz wysłać przez ssh, czy to przesyłanie strumieniowe, połączenia z hostem. itp. że z x powodów chcesz je zaszyfrować.
i zasady securecrt
Czasami używam SSH na bardzo podstawowym poziomie. Domyślny port to 22, prawda?
Tak więc, jeśli dobrze rozumiem, mój komputer jest hostem 1, a ten, z którym chcę się połączyć, to host2, ten tunel utworzyłby połączenie między portem 5000 a portem 23, a następnie trafiłby do portu 22?
Dlaczego warto zmieniać porty? Czy możesz stworzyć tunel z portem 22?
Bardzo ciekawy artykuł. Jak nano, chcę więcej!
SSH rzeczywiście domyślnie używa portu 22 (chociaż można to zmienić). Ten port jest portem używanym do faktycznej komunikacji między dwoma hostami. To ten, który musisz upewnić się, że jest otwarty i żadna zapora ogniowa go nie odcina. Ale dla użytkownika jest to całkowicie przejrzyste. Możesz o nim zapomnieć. W tym przykładzie przekierowanie odbywa się między portami 5000 i 23. Te dwa są jedynymi, o które musisz się martwić. Użytkownik zobaczy, że wszystko, co wyśle do portu 5000 swojego hosta, pojawi się na 23 hoście docelowym.
Oczywiście każdy użytkownik może przekierować porty, które uzna za odpowiednie.
Dziękuję za uwagi. To jest mój pierwszy post, a Twoje opinie pomogą ulepszyć następny.
Czy można to również zrobić za pomocą VPS?
Ok, to mój przypadek, PC1 ma dostęp do serwera, ale PC2 nie, oba łączą się przez ssh, chcę mieć dostęp w PC2, ale który port PC1 mam przekierować? jeśli w rzeczywistości chcę dotrzeć do portu serwera z PC2 i że pakiety mają PC1 jako źródłowy adres IP. czy rozumiem
Dajesz się zrozumieć. W takim przypadku potrzebujesz PC1, aby przekierować port PC2 na port 22 serwera:
PC2 $ ssh -L 5000: Serwer: 22 użytkowników PC1 @ PC1
i utrzymując to połączenie otwarte, z innego terminala:
PC2 $ ssh userServer @ localhost -p 5000
a ty już jesteś w środku.
Wreszcie funkcjonalne rozwiązanie !! Dziękuję Getafix, dałeś mi świat możliwości !!
Cieszę się!
Doskonały artykuł. Witamy w DesdeLinux ????
A co zrobić, jeśli mamy zablokowane 22? LOL..
Dzięki elav.
Jeśli masz zablokowany port 22, mmmm, będziemy musieli poszukać alternatywy dla zhakowania zapory XD
A co najgorsze (hipotetyczne): że jest blokowane przez dostawcę VPS.
Kilka godzin temu zdałem egzamin z pytaniami na ten temat 😛
Nie powiedziałbym tego:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
jest odpowiednikiem drugiej linii poleceń ... tej z opcją -L.
Ponieważ -R wskazuje, że port otwarty dla nowych połączeń znajduje się po stronie zdalnej, to znaczy po stronie serwera ssh; podczas gdy -L otwiera port po stronie lokalnej, po stronie klienta, aby otrzymywać nowe połączenia.
Tłumaczenie wiersza:
host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2
Byłoby to mniej więcej tak: Będąc na hoście 1, połącz się z serwerem ssh (port 22) hosta2 z moim użytkownikiem userhost2 i przekieruj połączenia wygenerowane na zdalnym porcie 5000 hosta 2 do portu 23 na hoście 1 (mój lokalny host)
Jeśli nie, popraw mnie! 😉
-
Z drugiej strony ... jeśli serwer zablokował wejście połączeń do portu 22, to znaczy, że nie możemy połączyć się zdalnie z serwerem ssh; co można zrobić to; że z serwera (znajomego sysadmin za zaporą zdalnego systemu host2) jest wykonywana linia poleceń:
host2 $ nohup ssh -fN -R 6000: localhost: 22 userhost1 @ host1
-f przechodzi do tła
-N nie wykonuje żadnego polecenia na pilocie
nohup zapobiega przerwaniu wykonywania polecenia podczas wylogowania
host1 $ ssh userhost2 @ localhost -p 6000
W ten sposób z host1 generujemy połączenie do localhost (ten sam host1) na porcie 6000, które przekieruje połączenie do portu 22 zdalnego systemu host2, na którym zalogujemy się jako użytkownik host2.
To pozwoliłoby (nie testowałem tego, ale wygląda na to, że działa) zalogować się do serwera ssh zablokowanego przez firewalla z niewielką pomocą od wewnątrz! 😀
O tym ostatnim przeczytałem z wyjaśnienia zamieszczonego w magazynie The Geek Stuff
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
Bardzo podoba mi się twoja publikacja; Często je czytam!
Pozdrowienia.
Masz rację. W artykule jest błąd. Przekierowania nie są równoważne. Polecenie host1 $ ssh -R 5000: localhost: 23 userhost2 @ host2 wykonuje odwrotne przekierowanie, to znaczy przekierowuje zdalny port 5000 na 23 lokalny, odwrotnie niż polecenie z -L.
Dziękuję za poprawę.