SSH NGINX-folyamrelén át anélkül, hogy eltörné

A PROXY fejléc üzenet annak a fogadónak, aki számít rá, a proxizott DNS-rekord pedig nem TCP-relé. A szegélyt és a felső folyamot külön javítsa.

A nyilvános SSH egy relén keresztül két egymástól független határon hibázik, és az egyik javítása rendszerint felfedi a másikat. Vagy a szegély HTTP-választ ad vissza folyam továbbítása helyett, vagy a relé olyan fejlécet tesz elé, amelyet a háttér soha nem vállalt olvasni. Három feltétel dönti el, melyiket látja: mire mutat valójában a nyilvános rekord, mit küld a folyamblokk felfelé, és melyik nevet ellenőrzi az SSH-kliens. Ebben a sorrendben haladjon.

Két határ, két tünet

A szegély hibája úgy néz ki, mintha HTTP-állapotoldal érkezne oda, ahol SSH-bannernek kellene lennie. A kapcsolat TCP-szinten létrejön, és az első bájtok egy webszerverhez tartozó szöveg. Ez protokoll-eltérés, nem elveszett csomag. Arra is figyelmeztet, hogy a szegély szándékosan mást szolgál ki az adott névhez.

A felső folyam hibája másképp néz ki. A kapcsolat eléri az sshd-t, az sshd olyan bájtokat olvas, amelyek nem a várt azonosítócsere, és a munkamenet meghal vagy megakad anélkül, hogy valaha kulcsot ajánlana.

A kettőt könnyű összetéveszteni, mert mindkettő olyan klienst eredményez, amely kapcsolódik, majd meghibásodik. Az első kapott protokollválasz az, ami megkülönbözteti őket, ezért annak a jegyben van a helye.

A PROXY fejléc üzenet, nem kapcsoló

A folyammodulban a proxy_protocol on arra utasítja az NGINX-et, hogy a hasznos teher előtt PROXY protokollfejlécet írjon a felső folyam felé. Ez nem kapcsolja be a TCP-proxizást, és semmi köze az SSH-titkosításhoz. Ez egy a fogadónak címzett megjegyzés. Ha a fogadó nem tudja elolvasni, törmelékké válik a folyam elején.

A fogadó szolgáltatásnak ezt a fejlécet szándékosan fel kell használnia. Egy normál sshd az SSH azonosítócserét várja a kapcsolat első bájtjaiként, ezért egy váratlan bevezető olyan módon töri meg a kézfogást, amely sérült szervernek látszik.

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

Ez a töredék egy működő relé teljes egésze a VPN-en át elérhető háttérhez. Semmilyen PROXY-direktíva nem jelenik meg, mert a fogadó nem beszéli a protokollt, és ez a hiány döntés, nem kihagyás.

A két irányt is válassza külön. A proxy_protocol beállítása a listen soron azt jelenti, hogy az NGINX azt várja, hogy a saját kliense küldi el először a fejlécet; egy közönséges SSH-kliensnél engedélyezve pontosan a fordítottját hozza annak a problémának, amelyet az emberek általában megpróbálnak megoldani.

Mit ér el valójában a nyilvános gépnév

Az HTTP 400 oldal egy SSH-munkamenetben bizonyíték a szegélyről. Valami az útvonalon HTTP-t beszél, és semmilyen kulcs- vagy fiókmunkától a háttérben ez nem változik meg. Fejezze be a háttér módosítását, amíg a szegély nincs rendben.

A Cloudflare szokásos proxizott rekordja a támogatott HTTP- és HTTPS-forgalmát meghatározott portokon hordozza. A proxy bekapcsolása egy gépnévhez nem hoz létre általános TCP-relét, és az SSH 443-as portra mozgatása nem teszi HTTPS-sé.

Két járható irány létezik. Egy csak DNS-rekord a saját TCP-reléjére mutathat, ami a kitettségről szóló döntést az Ön kezébe adja. Másik lehetőségként olyan terméket használjon, amely kifejezetten dokumentálja az SSH-szállítást, saját eredet-, kliens- és hozzáférés-konfigurációval.

Bármelyiket választja, a relének továbbra is szüksége van VPN-útvonalra a háttérhez, engedélyezett kapcsolatra és visszaútra. Az útvonal nem választható, mert a nyilvános oldal működik.

Tartsa stabilan az SSH-identitást egy álnéven keresztül

A felhasználók általában tovább akarják gépelni a meglévő gépnevüket. Az SSH-konfigurációban egy álnév ezt meg tudja tenni anélkül, hogy a relén bármit változtatna, és a változtatást a kliensoldalon tartja, ahová tartozik.

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

HostKeyAlias nélkül az OpenSSH a hosztkulcsot az alatt a név alatt keresi, amelyhez kapcsolódik, így a bejegyzés elmozdul, és minden felhasználó az első használatkor megváltozott kulcsra figyelmeztető üzenetet lát. Az álnév beállítása stabilan tartja a known-hosts bejegyzéseket, miközben a kapcsolat továbbra is a reléhez megy.

Ez az álnév csak az SSH-alapú távoli tárolókra vonatkozik. A HTTPS-es Git URL nem kérdezi meg, és a tipikus távoli URL-nek meg kell felelnie annak a szállításnak, amelyet ténylegesen létrehozott.

Amit nem szabad tennie, az a hosztkulcs-ellenőrzés kikapcsolása, hogy a figyelmeztetés eltűnjön. Ez eltávolít egy védelmet, amelyhez a továbbítás javítása soha nem kért hozzányúlást, és egy kozmetikai bosszúságot valódi kitettséggé változtat.

Minden ugrást külön ellenőrizzen

Tesztelje a nyilvános figyelőt önmagában, majd a relé és a háttér közötti kapcsolatot a relé hosztjáról, és csak ezután a klienst végponttól végpontig. E három teszt mindegyike más réteget zár ki. Egy kihagyása azt jelenti, hogy a maradék két eredmény nem értelmezhető. Három megfigyelés, három hely, ahol hiba lakhat.

Tartsa meg a célcímet, a portot és az első protokollbájtokat minden eredménynél. Ez a hármas különbözteti meg a szegélyhibát a VPN-útválasztási problémától és az SSH-hitelesítési hibától, és ez a különbség javítás és találgatás között.

Végül dokumentálja a tervezett kitettséget. Az a TCP-relé, amely SSH-t visz egy magán háttérhez, szándékos nyílás a nyilvános peremvonalon, és ugyanazt a felülvizsgálatot érdemli, mint bármely más bejövő szolgáltatás.

Kapcsolódó cikkek