Konto proxy SSH może działać bez powłoki

Utrzymaj przekazywanie SSH dostępne, wyłączając sesje powłoki i rozumiejąc granice wymuszania wyłącznie SOCKS.

Kuszącym ustawieniem jest AllowTcpForwarding no. Niestety wyłącza ono także przekazywanie, którego potrzebuje lokalny proxy SSH SOCKS. Przekazywanie dynamiczne nie jest furtką omijającą politykę serwera.

Dla dedykowanego konta OpenSSH rozdziela kilka możliwości. Fragment polityki może zezwalać na przekazywanie lokalne, blokując sesje powłoki i podsystemów:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

Podręcznik serwera opisuje MaxSessions 0 jako ustawienie blokujące sesje powłoki, logowania i podsystemów przy jednoczesnym zezwoleniu na przekazywanie. Włącz je do istniejącego uwierzytelnionego konta; nie jest to pełna konfiguracja bezpieczeństwa SSH.

Samo przekazywanie to nie tylko SOCKS

Stałe przekazywanie lokalne i żądanie SOCKS mogą ostatecznie poprosić serwer o ten sam rodzaj połączenia docelowego. Zezwolenie na przekazywanie lokalne nie gwarantuje, że klient użył konkretnego interfejsu SOCKS. Nie opisuj konta jako wymuszającego użycie wyłącznie SOCKS.

PermitOpen może ograniczyć pary hosta i portu docelowego, gdy konkretna lista spełnia wymaganie. Nie jest to ogólny zakaz uwzględniający rozwiązywanie nazw hostów dla każdej sieci prywatnej. Szersze ograniczenia adresów mogą wymagać odpowiedniej polityki sieci hosta.

Ustawienia konta, klucza i dołączonego serwera mogą dodatkowo ograniczyć przekazywanie. Ogólny zakaz przekazywania w innym miejscu może usunąć możliwość, którą ten fragment zdaje się zezwalać.

Użyj zwykłej procedury administracji serwerem ze ścieżką odzyskiwania, a następnie oceń osobno możliwości dozwolone i zabronione. Zamierzonym wynikiem są wyraźne uprawnienia do przekazywania, a nie interaktywne logowanie przypadkowo pozostawione dostępne czy proxy wyłączony przez własne ograniczenie.

Powiązane artykuły