MaxSessions, MaxStartups czy rejestracja urządzenia: który limit SSH wybrać

Usługi tuneli, które obiecują jedno urządzenie na abonenta, rzadko dostają tę obietnicę od MaxSessions, a pierwszy test zwykle to udowadnia. Abonent otwiera drugi proces ssh, pierwsza sesja nadal działa, a oba tunele przenoszą ruch. Każda opcja konfiguracji liczy coś innego, a żadna z nich nie liczy urządzeń. Nazwanie obietnicy najpierw sprawia, że wybór między nimi staje się oczywisty.

Co naprawdę liczy każda opcja

MaxSessions ogranicza liczbę otwartych sesji przenoszonych przez jedno uwierzytelnione połączenie sieciowe. Sesja oznacza tu powłokę, żądanie exec, podsystem taki jak SFTP lub podobny kanał multipleksowany w jednym transporcie SSH. Drugie wywołanie ssh otwiera drugi transport, uwierzytelnia się ponownie i otrzymuje własne pozwolenie. Liczba sesji pierwszego połączenia jest dla niego nieistotna.

MaxStartups ogranicza równoczesne połączenia, które nie zostały jeszcze uwierzytelnione, wyrażone jako próg początkowy, tempo i pełny próg. Istnieje po to, by seria na wpół otwartych uścisków dłoni nie mogła wyczerpać zasobów demona przed uwierzytelnieniem. Gdy klient się uwierzytelni, to połączenie przestaje liczyć się wobec MaxStartups i staje się czyjąś sesją. To nigdy nie był limit na użytkownika, a podniesienie go nie pozwala abonentowi zrobić więcej.

Reguła rejestracji urządzenia wcale nie jest opcją sshd. Należy ona do dowolnego systemu, który wydaje dane logowania i śledzi, które urządzenie je trzyma, co oznacza, że potrzebuje rejestracji, inwentarza i odwołania zamiast licznika. Wmieszanie tego wymagania do konfiguracji sshd to miejsce, w którym utyka większość takich projektów.

Gdzie MaxSessions przestaje być limitem

Blok Match User zmienia, które wartości konfiguracji dotyczą tego użytkownika, więc jest to naturalne miejsce, by ustawić surowszy MaxSessions dla konta usługi. Nie potrafi natomiast agregować między połączeniami, bo opcja jest oceniana na transport. Dwa transporty dostają każdy własny limit, a użytkownik kończy z podwojoną wartością tego, co pozwala blok.

Przekierowanie to osobna niespodzianka. Przekierowanie TCP nie potrzebuje kanału sesji, więc MaxSessions 0 może zabronić powłok i podsystemów, a mimo to zezwalać na tunele -L i -R. Usługa, która tylko przekierowuje i traktuje liczbę sesji jako swój limit tunelu, nie mierzy niczego. To zachowanie jest udokumentowane w referencji konfiguracji serwera OpenSSH i warto ją przeczytać przed projektowaniem wokół nazwy opcji.

Wypisz efektywną konfigurację, a nie plik, który według ciebie jest wczytany. Dołączenia i katalogi drop-in często oznaczają, że obowiązująca wartość nie jest wartością, którą edytowałeś.

MaxStartups chroni demona, nie abonenta

Trójdzielna forma MaxStartups opisuje, ile nieuwierzytelnionych połączeń może istnieć, zanim demon zacznie odrzucać procent nowych. Jej domyślna postać istnieje, ponieważ nieuwierzytelnione połączenie SSH jest tanie do otwarcia i drogie do utrzymania. To kontrola ochrony zasobów serwera i dotyczy wszystkich naraz.

Podniesienie go podczas burzy logowań zamienia ochronę demona na przyjęcie, co czasem jest właściwą wymianą i zawsze jest świadome. Nie robi nic dla abonenta, który chce drugiego tunelu, bo pierwszy tunel jest już uwierzytelniony. Mylenie obu prowadzi do zmiany, która naprawia zły objaw i jednocześnie osłabia serwer.

Gdy logowania są odrzucane seriami, zajrzyj do dziennika demona po komunikat przed uwierzytelnieniem, zanim dotkniesz którejkolwiek opcji. Komunikat nazywa strażnika, który zadziałał, a strażnicy nie są wymienni.

Gniazdo na użytkownika wymaga wspólnego stanu

Prawdziwa polityka jednego aktywnego transportu wymaga rezerwacji trzymanej gdzieś poza sshd. Krok przyjęcia musi atomowo zająć gniazdo konta, zwolnić je przy zamknięciu połączenia, wygasić je, gdy klient zniknie bez zamknięcia, i zdecydować, czy nowa próba jest odrzucana, czy zastępuje starą. Ta ostatnia decyzja jest decyzją produktową, nie technicznym szczegółem, bo zastąpienie aktywnego tunelu kogoś rozłącza.

Rezerwacja musi być też współdzielona przez każdy serwer, który akceptuje konto. Dwa hosty z niezależnymi lokalnymi licznikami egzekwują dwa osobne limity, a abonent, który łączy się ponownie przez drugą bramę, dostaje drugie gniazdo za darmo. Cokolwiek przechowuje stan, potrzebuje własnego zachowania przy awarii, bo nieosiągalny magazyn nie może zablokować wszystkich abonentów.

Dla obietnicy jednego urządzenia wydawaj osobne dane logowania dla każdego zarejestrowanego urządzenia i kontroluj rejestrację i odwołanie na tej warstwie. Skopiowany klucz prywatny nadal uwierzytelnia się z dowolnego miejsca, więc wydanie jednego klucza na użytkownika nie jest dowodem, ile maszyn go ma.

Sprawdź politykę dwoma prawdziwymi połączeniami

Napisz testy akceptacyjne jako polecenia, zanim napiszesz politykę. Pięć przypadków to drugi transport otwarty, gdy pierwszy jest aktywny, wiele kanałów w jednym transporcie, klient, który tylko przekierowuje porty, ponowne połączenie po zerwaniu łącza i to samo konto przybywające na inną bramę.

Najpierw przeczytaj efektywne limity, potem otwórz połączenia, które polityka powinna odrzucić. Obie połowy tego testu są ważne i żadna nie zastępuje drugiej.

sshd -T | grep -iE "maxsessions|maxstartups|allowtcpforwarding|permitopen"
ss -tn state established '( sport = :22 )' | head
ssh -N -L 8080:127.0.0.1:80 [email protected]

Uruchom polecenie tunelu dwa razy w dwóch terminalach i policz nawiązane połączenia na porcie 22. Jeśli oba przenoszą ruch, a twoja polityka twierdzi, że jest jeden aktywny transport, polityka jest dokumentacją, a nie egzekwowaniem. Napraw tę lukę w warstwie przyjęcia, a nie przez obniżenie MaxSessions i nadzieję, że drugi transport to zauważy.