SSH cez streamový prepájač NGINX bez jeho rozbitia

Hlavička PROXY je správa pre príjemcu, ktorý ju očakáva, a proxovaný DNS záznam nie je TCP prepájač. Opravte hranu a upstream oddelene.

Verejné SSH cez prepájač zlyháva na dvoch nesúvisiacich hraniciach a oprava jednej zvyčajne odhalí druhú. Hrana buď vracia odpoveď HTTP namiesto prenášania toku, alebo prepájač predradí hlavičku, s ktorej čítaním backend nikdy nesúhlasil. Ktorý prípad vidíte, určujú tri podmienky: na čo verejný záznam skutočne ukazuje, čo blok toku posiela do upstreamu a ktoré meno klient SSH overuje. Spracujte ich v tomto poradí.

Dve hranice, dva príznaky

Zlyhanie na hrane vyzerá ako stránka stavu HTTP, ktorá dorazí tam, kde má byť banner SSH. Spojenie sa dokončí na úrovni TCP a prvé bajty sú text patriaci webovému serveru. To je nesúlad protokolov, nie stratený paket. Hovorí vám aj to, že hrana pre to meno zámerne obsluhuje niečo iné.

Zlyhanie v upstreamu vyzerá inak. Spojenie dorazí do sshd, sshd prečíta bajty, ktoré nie sú očakávanou výmenou identifikácie, a relácia zomrie alebo visí bez toho, aby kedy ponúkla kľúč.

Obe sa ľahko zamieňajú, pretože obe dávajú klienta, ktorý sa pripojí a potom zlyhá. Prvá prijatá odpoveď protokolu je to, čo ich rozlíši, a preto patrí do tiketu.

Hlavička PROXY je správa, nie prepínač

V module toku proxy_protocol on prikazuje NGINX-u zapísať pred užitočným zaťažením smerom k upstreamu hlavičku protokolu PROXY. Nezapína proxy TCP a nemá nič spoločné so šifrovaním SSH. Je to poznámka adresovaná príjemcovi. Ak ju príjemca nedokáže prečítať, stane sa odpadom na začiatku toku.

Prijímajúca služba musí túto hlavičku vedome spotrebovať. Normálny sshd očakáva výmenu identifikácie SSH ako prvé bajty spojenia, takže neočakávaná preambula pokazí podanie ruky spôsobom, ktorý vyzerá ako poškodený server.

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

Tento fragment je celý funkčný prepájač pre backend dostupný cez VPN. Neobjavuje sa žiadna direktíva PROXY, pretože príjemca daný protokol nepozná, a táto neprítomnosť je rozhodnutie, nie opomenutie.

Oddeľte aj oba smery. Nastavenie proxy_protocol na riadku listen znamená, že NGINX očakáva, že jeho vlastný klient pošle hlavičku prvý; zapnutie pre bežného klienta SSH vytvorí presne opak problému, ktorý sa ľudia zvyčajne snažia vyriešiť.

Čo verejné meno hostiteľa skutočne dosiahne

Stránka HTTP 400 v relácii SSH je dôkaz o hrane. Niečo na ceste hovorí HTTP a žiadna práca s kľúčom alebo účtom na backende to nezmení. Prestaňte meniť backend, kým nebude hrana vyriešená.

Bežný proxovaný záznam Cloudflare prenáša podporovanú prevádzku HTTP a HTTPS na definovaných portoch. Zapnutie proxy pre meno hostiteľa nevytvára všeobecný TCP prepájač a presun SSH na port 443 z neho nerobí HTTPS.

Existujú dva schodné smery. Záznam iba s DNS môže ukazovať na váš vlastný TCP prepájač, čo dáva rozhodnutie o vystavení do vašich rúk. Prípadne použite produkt, ktorý výslovne dokumentuje prenos SSH, s vlastným nastavením pôvodu, klienta a prístupu.

Nech si vyberiete čokoľvek, prepájač stále potrebuje trasu VPN k backendu, povolené spojenie a spiatočnú cestu. Trasa nie je voliteľná, pretože verejná strana funguje.

Udržte identitu SSH stabilnú pomocou aliasu

Používatelia zvyčajne chcú ďalej písať svoje existujúce meno hostiteľa. Alias v konfigurácii SSH to dokáže bez zmeny čohokoľvek na prepájači a ponecháva zmenu na strane klienta, kam patrí.

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

Bez HostKeyAlias hľadá OpenSSH kľúč hostiteľa pod menom, ku ktorému sa pripája, takže sa záznam posunie a každý používateľ pri prvom použití uvidí varovanie o zmenenom kľúči. Nastavenie aliasu udrží záznamy v known-hosts stabilné, pričom spojenie stále smeruje k prepájaču.

Tento alias platí len pre vzdialené úložiská založené na SSH. URL Git cez HTTPS ho nekonzultuje a typická vzdialená URL musí zodpovedať transportu, ktorý ste skutočne zriadili.

Čo nesmiete urobiť, je vypnúť overovanie kľúča hostiteľa, aby varovanie zmizlo. Tým odstránite ochranu, ktorú oprava presmerovania nikdy nežiadala meniť, a premeníte kozmetickú nepríjemnosť na skutočné vystavenie.

Overujte každý skok zvlášť

Otestujte verejný poslucháč samostatne, potom spojenie od prepájača k backendu z hostiteľa prepájača a až potom klienta od konca do konca. Každý z tých troch testov vylučuje inú vrstvu. Vynechanie jedného znamená, že zvyšné dva výsledky nemožno interpretovať. Tri pozorovania, tri miesta, kde môže zlyhanie žiť.

Pri každom výsledku si ponechajte cieľovú adresu, port a prvé bajty protokolu. Táto trojica rozlišuje chybu hrany od problému s routingom VPN a od zlyhania autentizácie SSH, a to je rozdiel medzi opravou a hádaním.

Nakoniec zdokumentujte zamýšľané vystavenie. TCP prepájač, ktorý prenáša SSH k súkromnému backendu, je zámerné otvorenie vo verejnom perimetri a zaslúži si rovnakú revíziu ako akákoľvek iná prichádzajúca služba.

Súvisiace články