Dostęp SSH do hosta biurowego za routerem NAT

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

youatwork@officepc$ autossh -R 12345:localhost:22 notroot@serverpc

Później:

you@homepc$ autossh -L 23456:localhost:12345 notroot@serverpc

you@homepc$ ssh youatwork@localhost -p 23456

Co możesz zrobić, to: w kroku 1 przekieruj zdalny port z komputera biurowego na serwer ( 12345jest 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 nowpływa tylko na porty otwarte na cały świat, a nie lokalne tunele. Oto jakie są przekazywane porty:

homepc:
  outgoing ssh to serverpc:22
  listening localhost:23456 forwarded through ssh tunnel
serverpc:
  listening ssh at *:22
  incoming localhost ssh tunnel (from homepc) forwarded to localhost:12345
  listening localhost ssh tunnel (from officepc) forwarded from localhost:12345
officepc:
  outgoing ssh to serverpc:22
  incoming localhost through ssh tunnel (from serverpc) forwarded to localhost:22

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 GatewayPortsw ogóle nie jest sprawdzane.

Istnieje jednak dyrektywa AllowTcpForwarding: jeśli tak no, 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 ServerAliveIntervali ServerAliveCountMaxdo utrzymania tunelu w górze. Autossh ma wbudowaną kontrolę, ale najwyraźniej ma pewne problemy z Fedorą. -M0wyłącza to i -oServerAliveInterval=20 -oServerAliveCountMax=3sprawdza, czy połączenie jest aktywne - próbuje co 20 sekund, jeśli zawiedzie 3 razy z rzędu, zatrzymuje ssh (i autossh tworzy nowe):

  autossh -M0 -R 12345:localhost:22 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
  
  autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
  

• 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/configopcji (i portów) jest wskazane, w przeciwnym razie wiersze poleceń staną się zbyt szczegółowe. Na przykład:

  Host fwdserverpc
      Hostname serverpc
      User notroot
      ServerAliveInterval 20
      ServerAliveCountMax 3
      ExitOnForwardFailure yes
      LocalForward 23456 localhost:12345
  

Następnie możesz użyć tylko aliasu serwera:

    autossh -M0 fwdserverpc

Jeś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, ProxyCommandaby cicho podskakiwać przez serwer do wewnętrznego komputera za pośrednictwem nc(netcat)

# ~/.ssh/config on your home machine:
Host internalpc 
   ForwardAgent yes 
   ProxyCommand ssh user@server.example.com exec nc internal.pc.example.com %p

Następnie jesteś po prostu ssh user@internalpccicho przekazywany przez serwer, bez konieczności otwierania portów ani tuneli na żadnym końcu.

Zainstaluj Robo-TiTO na komputerze, do którego chcesz uzyskać dostęp do SSH zdalnie.

• Umożliwi to dostęp do SSH przy użyciu aplikacji klienckich Google Talk w dowolnym miejscu.
• Nie ma potrzeby publicznego adresu IP ani specjalnego ustawienia.
• Jest darmowy i open source, nie jest już płatny żadnej aplikacji.
• Nie musisz otwierać portu SSH (chroń swój komputer).
• Nie trzeba otwierać żadnego tunelowania (np. VPN lub coś takiego)

Poniższe instrukcje instalacji są nieaktualne, ponieważ witryna została przeniesiona. Nowy adres URL to https://github.com/formigarafa/robotito

Zrobiłem skrypt (przetestowany na moim systemie operacyjnym Raspbian w Raspberry Pi), abyś mógł łatwo zainstalować Robo-TiTO na Raspberry Pi, Debian lub Ubuntu Box (dystrybucja pakietów Debian). Oto kroki, aby zdalnie sterować urządzeniem Linux:

1. Otwórz Shell Shell lub możesz nazwać go Terminalem, przejdź do folderu domowego, Pobierz skrypt instalatora za pomocą polecenia:

   $ wget https://opengateway.googlecode.com/files/robotito
   

2. po tym uruchom skrypt, wpisując polecenie:

   $ sudo ./robotito
   

3. a następnie możesz edytować plik credentials.rbz folderu konfiguracji Robo-TiTO przy użyciu konta GTalk i zapisać go, naciskając Ctrl+ Xi Y. Domyślnie jest używany edytor nano.

4. uruchamianie Robo-TiTO z folderu Robo-TiTO za pomocą polecenia

   $ cd robotito
   $ ./jabbershd start
   

5. Po wykonaniu tej czynności możesz korzystać z SSH z dowolnego klienta Google Talk. Nie zapomnij dodać konta Robo-TiTO GTalk do konta Google talk i przetestować je, rozmawiając ze sobą przed użyciem konta.

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:

#!/bin/bash
TARGET_HOST=${1:-myserver.example.com}
TARGET_PORT=${2:-7777}
TUNNEL_PORT=${3:-22}
T_USER="odin"

#Check that we have an active connection to the remote system
ACTIVE_PROCESS=`ps -ef | \
    grep "ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT" | \
    grep -v grep | \
    wc -l`
if [ $ACTIVE_PROCESS -lt 1 ]; then
    echo "`date` : establishing connection to $TARGET_HOST on port $TARGET_PORT"
    screen -m -d ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT > /dev/null
fi

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.

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ą.