ssh na prywatny-ip


18

Mam komputer z CentOS (komputer A) skonfigurowany jako prywatny IP 10.150.5.141 (z ograniczoną zaporą ogniową), mogę uzyskać dostęp do Internetu i mój ArchLinux VPS (komputer B) z prawdziwym ip wxyz

Jak mogę zrobić inny komputer (komputer C), który mógłby uzyskać dostęp do komputera B, aby połączyć się z komputerem A, ale komputer C nie może połączyć się bezpośrednio z komputerem A (ponieważ znajduje się w prywatnej sieci A)?

Wiem, że tunel może otwierać porty lokalne na innym komputerze: port, ale jak zrobić odwrotnie?

Chcę uzyskać dostęp do komputera A za sshpomocą komputera B, ale komputer B nie może uzyskać dostępu do komputera A, ponieważ sieć na komputerze A jest restrykcyjna (może wyjść, ale nie może wejść, ponieważ nie mam dostępu do ich routera)

Chcę coś takiego:

ssh -connect-to w.x.y.z:22 -open-port vvv -forward-to 10.150.5.141 -port 22

tak, że kiedy będę ssh w.x.y.z:vvvz komputera C, zostanie przekierowany do sieci prywatnej 10.150.5.141:22.

Odpowiedzi:


14

To, czego szukasz, nazywa się tunelem zwrotnym. sshzapewnia to przez -Rprzełącznik:

-R [bind_address:]port:host:hostport
       Specifies that the given port on the remote (server) host is to 
       be forwarded to the given host and port on the local side.  This 
       works by allocating a socket to listen to port on the remote side, 
       and whenever a connection is made to this port, the connection is
       forwarded over the secure channel, and a connection is made to host 
       port hostport from the local machine.

Gdy OP odkrył swoją odpowiedź, składnia wygląda następująco:

$ ssh -f -N -R vvv:localhost:22 w.x.y.z

Przykład

Mam 2 komputery w sieci lappyi remotey. Więc uruchamiam następujące polecenie lappy:

$ ssh -f -N -R 12345:localhost:22 remotey

Mogę potwierdzić, że działa:

$ ps -eaf|grep "[l]ocalhost:22"
saml     27685     1  0 11:10 ?        00:00:00 ssh -f -N -R 12345:localhost:22 remotey

Teraz, jeśli sshosobno przejdę do systemu zdalnego remoteyi uruchomię to polecenie, widzę, że teraz akceptuje połączenia na porcie 12345 na lokalnym interfejsie systemu zdalnego:

$ netstat -an|grep :12345
tcp        0      0 127.0.0.1:12345             0.0.0.0:*                   LISTEN      
tcp        0      0 ::1:12345                   :::*                        LISTEN      

Testowanie połączenia

Możesz zobaczyć, że tunel zwrotny ssh działa w następujący sposób.

  1. Zaloguj się do remotey

    [user@lappy ~]$ ssh remotey
    
  2. przetestuj port tunelu zwrotnego

    [user@remotey ~]$ ssh -p 12345 localhost
    
  3. powinien teraz wrócić do lappy

    user@localhost's password: 
    Last login: Thu Aug  1 17:53:54 2013
    /usr/bin/xauth:  creating new authority file /home/user/.Xauthority
    [user@lappy ~]$ 
    

Porty na interfejsach innych niż localhost ( lo)?

Być może będziesz drapał się po głowie, jeśli spróbujesz wykonać takie polecenie i nie wydaje się ono działać lub zawsze wiąże się z portem lointerfejsu localhost ( ).

Na przykład:

lappy$ ssh -f -N -R remotey:12345:lappy:22 remotey

UWAGA: To polecenie mówi, aby otworzyć port 12345 @ remotey i tunelować wszelkie połączenia z portem 22 @ lappy.

Następnie na pilocie:

remotey$ netstat -an|grep 12345
tcp        0      0 127.0.0.1:12345              0.0.0.0:*                   LISTEN   

To, co się dzieje, to sshdkonfiguracje, które na to nie pozwalają. W rzeczywistości bez włączonej tej funkcji ( GatewayPorts) nie będziesz w stanie powiązać żadnych sshportów tunelu z niczym innym niż localhost.

Włączanie GatewayPorts

remotey$ grep GatewayPorts /etc/ssh/sshd_config
#GatewayPorts no

Aby go włączyć, edytuj ten plik /etc/ssh/sshd_config:

GatewayPorts clientspecified

I uruchom ponownie sshd:

remotey$ sudo service sshd restart

Teraz spróbuj ponownie i powinniśmy zobaczyć efekt, którego szukamy:

lappy$ ssh -f -N -R remotey:12345:lappy:22 remotey

I dwukrotnie sprawdź to tym razem w pilocie:

remotey$ netstat -anp | grep 12345
tcp        0      0 192.168.1.3:12345           0.0.0.0:*                   LISTEN      9333/sshd

UWAGA: Powyżej widać, że sshdproces nasłuchuje teraz na interfejsie, który ma adres IP 192.168.1.3, dla połączeń na porcie 12345.

Testowanie połączenia (część deux)

Teraz z naszą zmienioną konfiguracją, kiedy tym razem go testujemy. Podstawowa różnica polega na tym, że nie musimy już łączyć się z hostem lokalnym!

  1. Zaloguj się do remotey

    [user@lappy ~]$ ssh remotey
    
  2. przetestuj odwrotne połączenie

    [user@remotey ~]$ ssh -p 12345 remotey
    
  3. powinien teraz wrócić do lappy

    root@remotey's password: 
    Last login: Wed Aug 21 01:49:10 2013 from remotey
    [user@lappy ~]$ 
    

Bibliografia


Czy istnieje sposób na wykonanie tunelu od 0.0.0.0:12346 do 127.0.0.1:12345 na tej samej maszynie?
Kokizzu,

1
@Kokizzu - Próbowałem to skonfigurować i owijam się wokół osi wokół tego, o co prosisz. Znalazłem to, co brzmi jak chcesz, anattatechnologies.com/q/2012/08/chaining-ssh-tunnels . Spróbuję to później opracować wieczorem, nie krępuj się z nim zagrać i daj mi znać, jeśli zrobisz jakieś postępy.
slm

nie o to mi chodziło, chcę, żeby powiązał się z wxyz: vvv2 zamiast 127.0.0.1 (na komputerze B), aby inni ludzie mogli go również użyć ..
Kokizzu

1
@Kokizzu - zobacz aktualizacje.
slm

2

Ponieważ komputer B nie ma dostępu do komputera A, musisz najpierw otworzyć zdalny tunel z komputera A.

ssh user@computerB -R vvv:localhost:22

dzięki, ale czy istnieje sposób na otwarcie portu na adres IP eth0, który przekierował do usługi, która słuchała localhost?
Kokizzu,

1

nieważne, znalazłem odpowiedź:

ssh -f -N -R vvv:localhost:22 w.x.y.z

z komputera A

EDYCJA: TL; DR, prawidłowe rozwiązanie:

ssh -f -N -R w.x.y.z:vvv:localhost:22 w.x.y.z
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.