SSH kroz NGINX stream relej bez kvarenja

PROXY zaglavlje je poruka za primaoca koji ga očekuje, a proksirani DNS zapis nije TCP relej. Popravite ivicu i uzvodnu stranu odvojeno.

Javni SSH kroz relej pada na dvije nepovezane granice, a popravka jedne obično otkrije drugu. Ivica ili vraća HTTP odgovor umjesto da prenosi tok, ili relej ispred dodaje zaglavlje koje backend nikada nije pristao čitati. Tri uslova određuju na šta gledate: na šta javni zapis zaista pokazuje, šta blok toka šalje uzvodno i koje ime SSH klijent provjerava. Obradite ih tim redom.

Dvije granice, dva simptoma

Kvar na ivici izgleda kao HTTP stranica statusa koja stiže tamo gdje bi trebao biti SSH banner. Veza se uspostavlja na TCP nivou i prvi bajtovi su tekst koji pripada web serveru. To je nesklad protokola, a ne izgubljen paket. Takođe vam govori da ivica namjerno servira nešto drugo za to ime.

Kvar na uzvodnoj strani izgleda drugačije. Veza stiže do sshd, sshd čita bajtove koji nisu razmjena identifikacije koju očekuje, i sesija umire ili visi a da nikada ne ponudi ključ.

Ta dva je lako pobrkati jer oba daju klijenta koji se poveže i zatim padne. Prvi protokolni odgovor koji primite jeste ono što ih razlikuje, zato on i pripada u tiket.

PROXY zaglavlje je poruka, ne prekidač

U modulu toka proxy_protocol on nalaže NGINX-u da prema uzvodnoj strani zapiše zaglavlje PROXY protokola prije sadržaja. To ne uključuje TCP proksiranje i nema nikakve veze sa SSH enkripcijom. To je bilješka upućena primaocu. Ako je primalac ne može pročitati, postaje otpad na početku toka.

Usluga koja prima mora to zaglavlje namjerno konzumirati. Normalan sshd očekuje razmjenu identifikacije SSH kao prve bajtove veze, pa neočekivana preambula kvari rukovanje na način koji izgleda kao neispravan server.

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

Taj fragment je cjelina radnog releja za backend dostupan preko VPN-a. Nema PROXY direktive jer primalac ne govori taj protokol, a to odsustvo je odluka, a ne propust.

Razdvojite i oba smjera. Postavljanje proxy_protocol na liniju listen znači da NGINX očekuje da njegov vlastiti klijent prvo pošalje zaglavlje; uključivanje za običan SSH klijent proizvodi tačno suprotno od problema koji ljudi obično pokušavaju riješiti.

Šta javno ime hosta zaista doseže

HTTP 400 stranica u SSH sesiji dokaz je o ivici. Nešto na putu govori HTTP i nikakav rad na ključu ili računu na backendu to neće promijeniti. Prestanite mijenjati backend dok ivica ne bude riješena.

Običan proksirani zapis Cloudflare prenosi podržani HTTP i HTTPS saobraćaj na definisanim portovima. Uključivanje proksija za ime hosta ne stvara opšti TCP relej, a premještanje SSH-a na port 443 ne čini ga HTTPS-om.

Postoje dva izvodljiva smjera. Zapis samo za DNS može pokazivati na vaš vlastiti TCP relej, što odluku o izlaganju stavlja u vaše ruke. Alternativno, koristite proizvod koji izričito dokumentuje prijenos SSH-a, sa vlastitim postavkama porijekla, klijenta i pristupa.

Šta god izabrali, releju i dalje treba VPN ruta do backenda, dozvoljena veza i povratni put. Ruta nije opcionalna jer javna strana radi.

Održite SSH identitet stabilnim pomoću alijasa

Korisnici obično žele nastaviti tipkati svoje postojeće ime hosta. Alijas u SSH konfiguraciji to može učiniti bez ikakve promjene releja, i zadržava promjenu na strani klijenta gdje joj je mjesto.

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

Bez HostKeyAlias OpenSSH traži ključ hosta pod imenom na koje se povezuje, pa se zapis pomjera i svaki korisnik pri prvoj upotrebi vidi upozorenje o promijenjenom ključu. Postavljanje alijasa održava known-hosts zapise stabilnim dok veza i dalje ide na relej.

Ovaj alijas važi samo za udaljene repozitorije zasnovane na SSH-u. HTTPS Git URL ga ne konsultuje, a tipični URL udaljenog repozitorija mora odgovarati transportu koji ste zaista pripremili.

Ono što ne smijete učiniti jeste isključiti provjeru ključa hosta da biste uklonili upozorenje. To uklanja zaštitu koju popravka prosljeđivanja nikada nije tražila da se dotakne, i pretvara kozmetičku neprijatnost u stvarno izlaganje.

Provjerite svaki skok odvojeno

Testirajte javni slušalac samostalno, zatim vezu od releja do backenda sa hosta releja, i tek onda klijenta od početka do kraja. Svaki od ta tri testa isključuje drugi sloj. Preskakanje jednog znači da se preostala dva rezultata ne mogu tumačiti. Tri zapažanja, tri mjesta na kojima kvar može živjeti.

Čuvajte odredišnu adresu, port i prve bajtove protokola uz svaki rezultat. Ta trojka razlikuje grešku ivice od problema VPN rutiranja od kvara SSH autentifikacije, i to je razlika između popravke i nagađanja.

Na kraju, dokumentujte predviđeno izlaganje. TCP relej koji prenosi SSH do privatnog backenda namjerno je otvaranje u javnom perimetru i zaslužuje isti pregled kao i svaka druga ulazna usluga.

Povezani članci