Odwrotny SSH dla jednego urządzenia: nasłuch loopback czy trasowany VPN?

Twoje urządzenie stoi za NAT-em operatora, potrafi otwierać połączenia wychodzące i uruchamia serwer SSH, do którego nikt nie może dotrzeć. Przychodzące żądanie jest zwykle formułowane jako "daj mu VPN", co jest jedną z kilku odpowiedzi. Zanim je przyjmiesz, zdecyduj, czy potrzebujesz jednego administracyjnego portu TCP, czy trasowanej ścieżki do całej podsieci, bo to różne projekty z różną ekspozycją.

Odwrotny tunel dobrze odpowiada na wąską wersję. Urządzenie wywołuje twój hub, prosi hub o nasłuch na porcie loopback i przekazuje ten port z powrotem do własnej usługi SSH. Potem administratorzy docierają do nasłuchu przez hub, a nie przez publiczny internet.

Trzy warunki, które rozstrzygają wybór

Zapisz je przed jakąkolwiek konfiguracją. Są granicą między ograniczonym wejściem administracyjnym a rozszerzeniem sieci, a mieszanie ich to droga, na której tunel z pięciu linijek staje się płaską siecią bez właściciela.

Trzeci wiersz to ten, o który ludzie się spierają. Tunel do portu SSH urządzenia nie wprowadza jego sąsiadów do twojej sieci i nie powinien sprawiać takiego wrażenia przez łańcuch dalszych przekierowań. Jeśli wymaganiem naprawdę jest sieć LAN, powiedz to i zaprojektuj właśnie ją.

Strona huba: ograniczone konto przekaźnikowe

Daj każdemu urządzeniu własne konto przekaźnikowe z uwierzytelnianiem kluczem publicznym i bez sesji interaktywnej. Match blok ograniczony do tego konta trzyma uprawnienie małe, a klucz prywatny zostaje na urządzeniu, gdzie jest jego miejsce.

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

MaxSessions 0 to ta ciekawa linia. Odmawia sesji powłoki i podsystemów, a jednocześnie pozwala na przekazywanie, którego urządzenie potrzebuje, więc skradzionego klucza nie da się zamienić w interaktywne logowanie. PermitListen przypina adres i port nasłuchu po stronie huba oraz GatewayPorts no utrzymuje go na loopback zamiast otwierać go do sieci, w której stoi hub.

Przetestuj skuteczną konfigurację przed przeładowaniem i trzymaj przez cały czas otwartą drugą sesję. Match blok, który przypadkiem dotyczy wszystkich, albo literówka w nazwie opcji, to klasyczny sposób na zablokowanie się poza maszyną, którą utwardzasz. Zrzuć działającą konfigurację i odczytaj opcje ponownie, zamiast ufać plikowi, który właśnie zapisałeś. Pamiętaj, że obsługa opcji różni się między kompilacjami, więc linia przyjęta w nowszym serwerze może zostać po prostu zignorowana przez starszy.

Strona urządzenia: przekazywanie, które głośno zawodzi

Urządzenie otwiera połączenie i prosi o nasłuch. Dwa adresy w argumencie -R znaczą różne rzeczy, a czytanie ich od lewej do prawej to najszybszy sposób zapamiętania, który jest który.

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

Lewa para to miejsce, w którym hub ma nasłuchiwać. Prawa para to to, z czym urządzenie się łączy, gdy przychodzi żądanie, rozwiązywane po jego własnej stronie. Zamiana ich daje tunel, który czysto wstaje i przekazuje w złe miejsce, co jest gorsze niż awaria.

ExitOnForwardFailure=yes powoduje zakończenie polecenia, gdy żądany nasłuch nie może zostać ustanowiony, więc pętla restartów mówi prawdę, zamiast zostawiać na wpół działającą sesję. Nie mówi nic o tym, czy lokalna usługa SSH jest później zdrowa, więc połącz to z menedżerem procesów i okazjonalnym prawdziwym testem połączenia.

Nigdy nie zastępuj adresu nasłuchu loopback znakiem wieloznacznym, żeby uniknąć dodatkowego przeskoku. Ta jedna zmiana to różnica między ścieżką zarządzania a portem osiągalnym publicznie, i zwykle zdarza się podczas debugowania, a potem zostaje. Jeśli współpracownik nie dociera do portu przez hub, napraw konfigurację przeskoku zamiast poszerzać przypisanie. Loopback to cały argument bezpieczeństwa tego projektu.

Dostęp administratora przez hub

Administrator ze zwykłym kontem na hubie może przeskoczyć przez niego do przekazanego portu. Konto przekaźnikowe nie służy do tego i właśnie w tym jest sens trzymania ich osobno.

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

Zweryfikuj klucz hosta urządzenia pod wybranym aliasem, bo ten klucz identyfikuje urządzenie na końcu łańcucha, a tunel jest tylko transportem. Logowanie od końca do końca nadal uwierzytelnia oba końce; tunel kończący się na wspólnym hubie nie czyni go przez to zaufaną ścieżką.

Przejmij cykl życia

Uruchamiaj polecenie urządzenia pod menedżerem procesów z dokładnie jedną aktywną instancją i polityką restartu, którą wybrałeś świadomie. Opcje keepalive wykrywają martwego partnera; nie wskrzeszają procesu, który zakończył działanie.

Następnie napisz procedurę wycofania. Każde urządzenie ma własny nasłuch i własny klucz, więc wycofanie oznacza odwołanie tego konta i usunięcie tego klucza, a nie rotację sekretu wspólnego dla całej floty.

Na koniec pamiętaj, co daje ci loopback. Ogranicza ekspozycję sieciową i nie robi nic z innymi lokalnymi użytkownikami na wspólnym hubie, więc polityka dostępu samego huba nadal musi być poprawna. Dokumentacja sshd_config opisuje każdą z użytych powyżej opcji, i warto przeczytać sekcje przekazywania w całości, zanim którąkolwiek z nich poszerzysz.