Chciałbym uzyskać dostęp do portu ssh mojego biurowego hosta Linux z domu. Niestety host znajduje się za routerem NAT. Dlatego adres IP nie jest publicznie dostępny. Istnieje jednak dostęp do innego hosta internetowego (serwera), który niestety jest tylko dostępem innym niż root. Po chwili poszukiwań nie znajduję odpowiedniego rozwiązania.
Po instalacji:
- Komputer biurowy (Linux, dostęp do roota) za NAT (IP niepubliczne), ale pełny dostęp do Internetu.
- Serwer PC (Linux, bez dostępu roota) statyczny i publiczny adres IP oraz pełny dostęp do Internetu.
- Komputer domowy (Linux, dostęp do roota) za NAT (IP niepubliczne), ale pełny dostęp do Internetu.
Możliwe połączenia: Office PC -> Server <- Home PC
Niemożliwe: komputer biurowy <-X- serwer -X-> komputer domowy
Ani komputer domowy, ani serwer nie mogą zainicjować dostępu do komputera biurowego. Ale zarówno komputer biurowy, jak i komputer domowy mogą inicjować połączenia z serwerem.
Odwrotny tunel SSH nie jest możliwy: próbowałem metody zwanej odwrotnym tunelem ssh. Niestety wymaga to GatewayPorts na serwerze ustawionego na „tak” w / etc / ssh / sshd_config, gdzie nie mam dostępu do roota.
Zasadniczo powinno być możliwe:
0) Na serwerze uruchamiam program przestrzeni użytkownika, który nasłuchuje na 2 portach (1 przychodzącym, 1 wychodzącym)
1) Na komputerze w biurze uruchamiam inny program, który utrzymuje połączenie TCP otwarte z portem wychodzącym na serwerze.
2) Z domu podłączam się do portu wejściowego serwera.
Tam powinno być standardowe rozwiązanie tego problemu.
Jakie jest najszybsze i najczystsze rozwiązanie tego problemu?
Szczery
Odpowiedzi:
Później:
Co możesz zrobić, to: w kroku 1 przekieruj zdalny port z komputera biurowego na serwer (
12345
jest używany jako przykład, każdy port> 1024 powinien zrobić). Teraz połączenie z 12345 na serwerze powinno połączyć cię z portem 22 na officepc.W kroku 2 przekaż port 23456 z komputera domowego na 12345 na serwerze (skąd zostanie on przesłany do officepc: 22, zgodnie z konfiguracją w kroku 1)
W kroku 3 łączysz się z lokalnym portem 23456 przy użyciu loginu komputera biurowego . Jest to przekazywane krok 2 do portu 12345 na serwerze, a krok 1 na komputer w biurze.
Zauważ, że używam autossh do przekazywania, ponieważ jest to opakowanie ssh, które automatycznie łączy tunel, jeśli zostanie ono odłączone; jednak normalne ssh również działałoby, o ile połączenie nie zostanie zerwane.
Możliwa jest luka: każdy, kto może połączyć się z localhost: 12345 na serverpc, może teraz połączyć się z officepc: 22 i spróbować włamać się do niego. (Pamiętaj, że jeśli używasz serwera SSH, powinieneś zabezpieczyć go ponad podstawowymi zabezpieczeniami, które są domyślnie włączone; Zalecam przynajmniej wyłączenie logowania roota i uwierzytelnienia hasła - patrz np. To )
Edycja : Sprawdziłem to przy tej samej konfiguracji i działa.
GatewayPorts no
wpływa tylko na porty otwarte na cały świat, a nie lokalne tunele. Oto jakie są przekazywane porty:Tak więc, jeśli chodzi o stos sieciowy, to cały ruch lokalny na odpowiednich interfejsach sprzężenia zwrotnego (plus połączenia ssh z serverpc); dlatego
GatewayPorts
w ogóle nie jest sprawdzane.Istnieje jednak dyrektywa
AllowTcpForwarding
: jeśli takno
, to konfiguracja zakończy się niepowodzeniem, ponieważ żadne przekazywanie nie jest w ogóle dozwolone, nawet przez interfejs sprzężenia zwrotnego.Ostrzeżenia :
jeśli używasz autossh i niedawnego ssh, możesz chcieć użyć ssh
ServerAliveInterval
iServerAliveCountMax
do utrzymania tunelu w górze. Autossh ma wbudowaną kontrolę, ale najwyraźniej ma pewne problemy z Fedorą.-M0
wyłącza to i-oServerAliveInterval=20 -oServerAliveCountMax=3
sprawdza, czy połączenie jest aktywne - próbuje co 20 sekund, jeśli zawiedzie 3 razy z rzędu, zatrzymuje ssh (i autossh tworzy nowe):przydatne może być zrestartowanie tunelu ssh, jeśli przekazywanie nie powiedzie się, przy użyciu
-oExitOnForwardFailure=yes
- jeśli port jest już związany, możesz uzyskać działające połączenie SSH, ale nie przekierowany tunel.użycie
~/.ssh/config
opcji (i portów) jest wskazane, w przeciwnym razie wiersze poleceń staną się zbyt szczegółowe. Na przykład:Następnie możesz użyć tylko aliasu serwera:
źródło
GatewayPorts no
ogranicza otwarte porty, aby były dostępne tylko w interfejsie sprzężenia zwrotnego; zwróć uwagę, że w kroku 2 przekazujesz dalej na interfejsie sprzężenia zwrotnego (w rzeczywistości oba przekazy są „tylko hostem lokalnym”), więc może to działać (AllowTcpForwarding no
w konfiguracji sshd to zepsuje).GatewayPorts no
; zredagował odpowiedź. Zauważ, że istnieją inne dyrektywy (takie jakPermitOpen
iAllowTcpForwarding
), które mogą złamać tę konfigurację: manpagez.com/man/5/sshd_configJeśli możesz ssh do wewnętrznego serwera z domu i z wewnętrznego serwera do biurowego komputera z systemem Linux, to z domu możesz użyć ssh,
ProxyCommand
aby cicho podskakiwać przez serwer do wewnętrznego komputera za pośrednictwemnc
(netcat)Następnie jesteś po prostu
ssh user@internalpc
cicho przekazywany przez serwer, bez konieczności otwierania portów ani tuneli na żadnym końcu.źródło
Zainstaluj Robo-TiTO na komputerze, do którego chcesz uzyskać dostęp do SSH zdalnie.
Poniższe instrukcje instalacji są nieaktualne, ponieważ witryna została przeniesiona. Nowy adres URL to https://github.com/formigarafa/robotito
źródło
CLIENT_PASSPHRASE = "logmein"
w postaci zwykłego tekstu . To dosłownie zero bezpieczeństwa - robisz dziurę wielkości ciężarówki, do której każdy może wejść. Kontrast z uwierzytelnianiem klucza publicznego SSH: uwierzytelniam się w bezpiecznym kanale, używając poświadczeń, które nigdy nie przekraczają granicy. Kto teraz dba o bezpieczeństwo swojego komputera?Rozwiązanie Piskvor działa i jest fajne. Jednak utrzymuje terminale wiszące z zawieszonymi powłokami logowania. Niezbyt fajnie.
Zawsze używałem tego małego skryptu, który napisałem, aby połączyć się z serwerem i utrzymywać go w kontakcie, uruchamiając go w cronie:
Założę się, że możemy naprawić rozwiązanie Piskvor za pomocą bardziej eleganckiego autossh obok może odłączonego ekranu lub użyć argumentów -NT ssh, aby utrzymać połączenie w tle.
źródło
homepc
komputerze).Wydaje mi się, że zamiast tunelu SSH powinieneś wypróbować VPN: taki, który działa, używając zewnętrznego serwera do pośredniczenia, takiego jak Hamachi . Istnieją inne darmowe programy, takie jak ten, ale Hamachi jest moją ulubioną.
źródło
5.0.0.0/8
sieć faktycznie ma przypisane publiczne adresy IPv4, Hamachi ma kłopoty (jeśli Hamachi jest uruchomiony, nie możesz uzyskać dostępu do nieco przypadkowej części Internetu). Ponadto Hamachi nie jest już darmowy.