SSH przez przekaźnik strumienia NGINX bez psucia go

Nagłówek PROXY to komunikat do odbiorcy, który go oczekuje, a proxowany rekord DNS nie jest przekaźnikiem TCP. Napraw krawędź i górną stronę osobno.

Publiczny SSH przez przekaźnik zawodzi na dwóch niepowiązanych granicach, a naprawa jednej zwykle ujawnia drugą. Albo krawędź zwraca odpowiedź HTTP zamiast przenosić strumień, albo przekaźnik dodaje z przodu nagłówek, na którego czytanie backend nigdy się nie zgodził. Trzy warunki decydują, który przypadek widzisz: na co faktycznie wskazuje publiczny rekord, co blok strumienia wysyła w górę i jaką nazwę weryfikuje klient SSH. Zajmij się nimi w tej kolejności.

Dwie granice, dwa objawy

Awaria na krawędzi wygląda jak strona statusu HTTP docierająca tam, gdzie powinien być baner SSH. Połączenie kończy się na poziomie TCP, a pierwsze bajty to tekst należący do serwera WWW. To niezgodność protokołu, nie zgubiony pakiet. Mówi też, że krawędź celowo obsługuje coś innego dla tej nazwy.

Awaria po stronie nadrzędnej wygląda inaczej. Połączenie dociera do sshd, sshd czyta bajty, które nie są oczekiwaną wymianą identyfikacji, i sesja ginie albo wisi, nie oferując nigdy klucza.

Te dwa łatwo pomylić, bo oba dają klienta, który się łączy, a potem zawodzi. Pierwsza otrzymana odpowiedź protokołu jest tym, co je rozróżnia, dlatego należy do zgłoszenia.

Nagłówek PROXY to komunikat, nie przełącznik

W module strumienia proxy_protocol on nakazuje NGINX-owi zapisać przed ładunkiem nagłówek protokołu PROXY w stronę nadrzędną. Nie włącza to proxy TCP i nie ma nic wspólnego z szyfrowaniem SSH. To notatka adresowana do odbiorcy. Jeśli odbiorca nie potrafi jej przeczytać, staje się śmieciem na początku strumienia.

Usługa odbierająca musi świadomie skonsumować ten nagłówek. Zwykły sshd oczekuje wymiany identyfikacji SSH jako pierwszych bajtów połączenia, więc nieoczekiwana preambuła psuje uścisk dłoni w sposób, który wygląda jak uszkodzony serwer.

stream {
    server {
        listen 2222;
        proxy_pass 10.77.0.20:22;
    }
}

Ten fragment to cały działający przekaźnik dla backendu osiągalnego przez VPN. Nie pojawia się żadna dyrektywa PROXY, bo odbiorca nie mówi tym protokołem, a ta nieobecność jest decyzją, nie pominięciem.

Rozdziel też oba kierunki. Ustawienie proxy_protocol w wierszu listen oznacza, że NGINX oczekuje, iż jego własny klient wyśle nagłówek pierwszy; włączenie tego dla zwykłego klienta SSH daje dokładnie odwrotność problemu, który ludzie zwykle próbują rozwiązać.

Do czego faktycznie dociera publiczna nazwa hosta

Strona HTTP 400 w sesji SSH jest dowodem dotyczącym krawędzi. Coś na ścieżce mówi po HTTP, a żadna praca z kluczem ani kontem na backendzie tego nie zmieni. Przestań zmieniać backend, dopóki krawędź nie jest uporządkowana.

Zwykły proxowany rekord Cloudflare przenosi obsługiwany ruch HTTP i HTTPS na określonych portach. Włączenie proxy dla nazwy hosta nie tworzy ogólnego przekaźnika TCP, a przeniesienie SSH na port 443 nie czyni go HTTPS.

Istnieją dwa wykonalne kierunki. Rekord tylko DNS może wskazywać na twój własny przekaźnik TCP, co oddaje decyzję o ekspozycji w twoje ręce. Alternatywnie użyj produktu, który jawnie dokumentuje transport SSH, z własną konfiguracją źródła, klienta i dostępu.

Cokolwiek wybierzesz, przekaźnik nadal potrzebuje trasy VPN do backendu, dozwolonego połączenia i drogi powrotnej. Trasa nie jest opcjonalna, ponieważ strona publiczna działa.

Utrzymaj tożsamość SSH stabilną dzięki aliasowi

Użytkownicy zwykle chcą nadal wpisywać swoją dotychczasową nazwę hosta. Alias w konfiguracji SSH może to zrobić bez zmieniania czegokolwiek w przekaźniku i zachowuje zmianę po stronie klienta, gdzie jej miejsce.

Host git.example.com
    HostName ssh-entry.example.net
    Port 2222
    User git
    HostKeyAlias git.example.com

Bez HostKeyAlias OpenSSH szuka klucza hosta pod nazwą, z którą się łączy, więc wpis się przesuwa i każdy użytkownik przy pierwszym użyciu widzi ostrzeżenie o zmienionym kluczu. Ustawienie aliasu utrzymuje wpisy known-hosts stabilne, a połączenie nadal idzie do przekaźnika.

Ten alias dotyczy tylko zdalnych repozytoriów opartych na SSH. Adres Git HTTPS go nie konsultuje, a typowy adres zdalny musi odpowiadać transportowi, który faktycznie przygotowałeś.

Czego nie wolno ci zrobić, to wyłączenie weryfikacji klucza hosta, żeby ostrzeżenie zniknęło. To usuwa ochronę, której naprawa przekazywania nigdy nie prosiła dotykać, i zamienia kosmetyczną uciążliwość w realną ekspozycję.

Weryfikuj każdy przeskok osobno

Przetestuj publiczny nasłuch samodzielnie, potem połączenie od przekaźnika do backendu z hosta przekaźnika, a dopiero potem klienta od końca do końca. Każdy z tych trzech testów wyklucza inną warstwę. Pominięcie jednego oznacza, że pozostałych dwóch wyników nie da się zinterpretować. Trzy obserwacje, trzy miejsca, w których może mieszkać awaria.

Zachowaj adres docelowy, port i pierwsze bajty protokołu przy każdym wyniku. Ten tercet odróżnia błąd krawędzi od problemu z routingiem VPN i od niepowodzenia uwierzytelniania SSH, i to jest różnica między naprawą a domysłem.

Na koniec udokumentuj zamierzoną ekspozycję. Przekaźnik TCP, który przenosi SSH do prywatnego backendu, jest świadomym otwarciem w publicznym obwodzie i zasługuje na taki sam przegląd jak każda inna usługa przychodząca.

Powiązane artykuły