Niestety w artykule są spore błędy i w sumie kwalifikują znalezisko do zakopania. W pierwszym przykładzie opcja -L powoduje otwarcie przez klienta SSH portu na interfejsie localhost. Nic więc nie zostanie wystawione na zewnątrz.
Dodatkowo zdanie "Użycie 0.0.0.0 zamiast konkretnego adresu IP spowoduje, że docelowy port będzie nasłuchiwał na wszystkich interfejsach naszej maszyny" jest kompletną bzdurą. Zarówno adres IP jak i drugi port mówią DOKĄD ma się połączyć serwer SSH, na który
@zarowka12: Przede wszystkim - Serdecznie dzięki za konstruktywną krytykę, choć można było wylać wiadro pomyj. M. in. dzięki Twojemu wpisowi zgłębiłem temat dużo bardziej, poprawiłem wszystkie przykłady. Przede wszystkim jednak wyciągnąłem wnioski na przyszłość i sprawdziłem każde z poleceń w domowym laboratorium.
Obecnie artykuł jest dużo lepszej jakości! Jeszcze raz dzięki!
R-ka jest fajna jak chcesz pokazać swój projekt/usługę a jesteś za natem bez możliwości otwierania portów. Otwierasz port na serwerze ssh i przekierowujesz go na lokalny host i twoja usługa jest widoczna na zewnątrz. Przegenialne w swojej prostocie. Przydało by się info że przy R-ce trzeba prze konfigurować sshd i zmienić GatewayPorts z no na yes. Bez tego nie zadziała. Na L-ce mam wszystkie połączenia typu zdalny pulpit połączenia do baz. Imho
Jest jakiś sposób dostać się z zewnątrz za natem bez publicznego ipv4?
@yjkis: chodzi o to, że masz swój komputer za NAT-em, ale dysponujesz jednocześnie serwerem mającym publiczne IPv4. Wtedy logujesz się na ten serwer z opcją -R i on otwiera port, który zostaje przekierowany na Twój komputer. Czyli tworzy się przekierowanie portu a dane lecą wewnątrz sesji SSH. Czyli to, co wystawiasz na komputerze może być wystawione nawet jedynie na
@yjkis: https://www.ssh.com/ssh/tunneling/example#sec-Remote-Forwarding W artykule też to masz. Jeśli serwer ssh jest na publicznym to ssh -nNT -R 3080:localhost:1080 user@server1 i jak ktoś się łączy do ipserwerassh:3080 to zostanie przekierowany do twojego hosta na port 1080
@TzK_: U nas w korpo było kiedyś tak, że nie mieliśmy dostępu z korposieci do neta. Na szczęście były jakieś komputery gdzieś w Szwecji z których dało się dobić do korporacyjnego proxy z bramą na zewnątrz. Kto umiał się bawić SSH to sobie poustawiał kilka tunelów prze kolejne hosty i neta miał. W końcu administracja IT się zorientowała i wysłali majla na wspólny alias firmowy z tytułem: "Do wszystkich tunelarzy" (
Reverse SSH Tunnel używałem wiele razy już, bo u mojego dostawcy nie da się portów przekierować i przez to nie mogę niczego nawet na pare minut udostępnić. IPv6 na zewnątrz działa, ale niezawsze druga strona ma IPv6 - dlatego w tych przypadkach odpalam -R'ke na VPSa i podaje IP swojego VPSa+Port i druga strona ląduje u mnie na PC ( ͡°͜ʖ͡°) Wspaniałość.
Również przykład 1.3 nie ma prawa działać i świadczy o tym, że autor zapomniał przeczytać dokumentację. Tutaj celem jest lokalne udostępnienie portu otwartego na serwerze znajdującym się za NAT-em. Wówczas trzeba się zalogować na server2 z opcją -L 1080:server3:3080 Wtedy logując się na port 1080 na localhoście połączymy się z portem 3080 na server3. Opcja -R nie ma tu sensu, bo otwiera ona port na serwerze on już jest otwarty i to
Komentarze (82)
najlepsze
Dodatkowo zdanie "Użycie 0.0.0.0 zamiast konkretnego adresu IP spowoduje, że docelowy port będzie nasłuchiwał na wszystkich interfejsach naszej maszyny" jest kompletną bzdurą. Zarówno adres IP jak i drugi port mówią DOKĄD ma się połączyć serwer SSH, na który
źródło: comment_ol3lfNqAAFbrYszqYhZuUwpfWKrBHYs2.jpg
PobierzObecnie artykuł jest dużo lepszej jakości! Jeszcze raz dzięki!
Otwierasz port na serwerze ssh i przekierowujesz go na lokalny host i twoja usługa jest widoczna na zewnątrz. Przegenialne w swojej prostocie.
Przydało by się info że przy R-ce trzeba prze konfigurować sshd i zmienić GatewayPorts z no na yes. Bez tego nie zadziała.
Na L-ce mam wszystkie połączenia typu zdalny pulpit połączenia do baz. Imho
@yjkis: chodzi o to, że masz swój komputer za NAT-em, ale dysponujesz jednocześnie serwerem mającym publiczne IPv4. Wtedy logujesz się na ten serwer z opcją -R i on otwiera port, który zostaje przekierowany na Twój komputer. Czyli tworzy się przekierowanie portu a dane lecą wewnątrz sesji SSH. Czyli to, co wystawiasz na komputerze może być wystawione nawet jedynie na
W artykule też to masz. Jeśli serwer ssh jest na publicznym to
ssh -nNT -R 3080:localhost:1080 user@server1
i jak ktoś się łączy do ipserwerassh:3080 to zostanie przekierowany do twojego hosta na port 1080
W końcu administracja IT się zorientowała i wysłali majla na wspólny alias firmowy z tytułem: "Do wszystkich tunelarzy" (
-L 1080:server3:3080
Wtedy logując się na port 1080 na localhoście połączymy się z portem 3080 na server3. Opcja -R nie ma tu sensu, bo otwiera ona port na serwerze on już jest otwarty i to
Tiaaa... i później wygląda to tak.
( ͡° ͜ʖ ͡°)
źródło: comment_czNeC3I02VJYcANfp0VYMWsUQfewIQKh.jpg
Pobierz@HardyChop: @zarowka12: Poprawiłem oraz uzupełniłem artykuł. Przede wszystkim jednak wyciągnąłem wnioski na przyszłość. Pozdrawiam.