SSH läbi NGINX-i voo-vahendaja ilma seda rikkumata

PROXY-päis on sõnum vastuvõtjale, kes seda ootab, ja proksitud DNS-kirje ei ole TCP-vahendaja. Paranda serv ja ülemvool eraldi.

Avalik SSH läbi vahendaja nurjub kahel omavahel mitteseotud piiril ja ühe parandamine paljastab tavaliselt teise. Kas serv tagastab HTTP-vastuse voo edastamise asemel või lisab vahendaja ette päise, mida taustarakendus ei ole kunagi nõustunud lugema. Kolm tingimust otsustavad, kumba te näete: millele avalik kirje tegelikult osutab, mida voo plokk ülesvoolu saadab ja millist nime SSH-klient kontrollib. Käsitlege neid selles järjekorras.

Kaks piiri, kaks sümptomit

Tõrge servas näeb välja nagu HTTP olekuleht, mis saabub sinna, kus peaks olema SSH-bänner. Ühendus lõpeb TCP tasandil ja esimesed baidid on tekst, mis kuulub veebiserverile. See on protokolli lahknevus, mitte kadunud pakett. See ütleb teile ka, et serv teenindab selle nime jaoks teadlikult midagi muud.

Tõrge ülesvoolu poolel näeb välja teisiti. Ühendus jõuab sshd-ni, sshd loeb baite, mis ei ole oodatud identifitseerimisvahetus, ja seanss sureb või jääb rippuma, ilma et kunagi pakutaks võtit.

Neid kahte on lihtne segi ajada, sest mõlemad annavad kliendi, mis ühendub ja seejärel nurjub. Esimene protokollivastus, mille te saate, eristab neid, ja seetõttu kuulub see piletisse.

PROXY-päis on sõnum, mitte lüliti

Voo moodulis käsib proxy_protocol on NGINX-il kirjutada enne kasulikku koormust ülesvoolu suunas PROXY-protokolli päise. See ei luba TCP proksimist ja sellel pole SSH-krüpteerimisega midagi pistmist. See on vastuvõtjale adresseeritud märkus. Kui vastuvõtja ei suuda seda lugeda, muutub see voo alguses prahiks.

Vastuvõttev teenus peab selle päise teadlikult tarbima. Tavaline sshd ootab SSH identifitseerimisvahetust ühenduse esimeste baitidena, seega ootamatu sissejuhatus rikub kätlust viisil, mis näeb välja nagu rikutud server.

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

See fragment on tervikuna toimiv vahendaja VPN-i kaudu kättesaadava taustarakenduse jaoks. Ühtegi PROXY-direktiivi ei ilmu, sest vastuvõtja ei räägi seda protokolli, ja see puudumine on otsus, mitte vahelejätmine.

Eraldage ka kaks suunda. proxy_protocol seadmine reale listen tähendab, et NGINX ootab, et tema enda klient saadaks päise esimesena; selle lubamine tavalise SSH-kliendi jaoks tekitab täpselt vastupidise probleemi, mida inimesed tavaliselt lahendada püüavad.

Mida avalik hostinimi tegelikult saavutab

HTTP 400 leht SSH-seansis on tõend serva kohta. Midagi teel räägib HTTP-d ja mingi võtme- või kontotöö taustarakenduses ei muuda seda. Lõpetage taustarakenduse muutmine, kuni serv on selgeks tehtud.

Cloudflare'i tavaline proksitud kirje kannab oma toetatud HTTP- ja HTTPS-liiklust määratud portidel. Proksi sisselülitamine hostinime jaoks ei loo üldist TCP-vahendajat ja SSH viimine pordile 443 ei tee sellest HTTPS-i.

On kaks teostatavat suunda. Ainult DNS-i kirje võib osutada teie enda TCP-vahendajale, mis jätab kokkupuute otsuse teie kätesse. Teise võimalusena kasutage toodet, mis dokumenteerib SSH-veo selgesõnaliselt, oma päritolu-, kliendi- ja juurdepääsukonfiguratsiooniga.

Ükskõik mida te valite, vajab vahendaja endiselt VPN-marsruuti taustarakendusse, lubatud ühendust ja tagasiteed. Marsruut ei ole valikuline, sest avalik pool töötab.

Hoidke SSH identiteet aliase kaudu stabiilsena

Kasutajad tahavad tavaliselt oma olemasolevat hostinime edasi trükkida. SSH-konfiguratsiooni alias suudab seda teha, ilma vahendajas midagi muutmata, ja hoiab muudatuse kliendi poolel, kuhu see kuulub.

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

Ilma HostKeyAlias-ita otsib OpenSSH hostivõtit nime alt, millega see ühendub, seega kirje liigub ja iga kasutaja näeb esimesel kasutamisel hoiatust muudetud võtme kohta. Aliase seadmine hoiab known-hosts kirjed stabiilsena, samal ajal kui ühendus läheb endiselt vahendajale.

See alias kehtib ainult SSH-põhiste kaugrepositaariumide puhul. HTTPS-i Git URL ei konsulteeri seda ja tüüpiline kaug-URL peab vastama transportimisviisile, mille te tegelikult ette valmistasite.

Mida te ei tohi teha, on hostivõtme kontrollimise väljalülitamine, et hoiatus kaoks. See eemaldab kaitse, mida edastamise parandus ei palunud kunagi puutuda, ja muudab kosmeetilise ebamugavuse tõeliseks kokkupuuteks.

Kontrollige iga hüpet eraldi

Testige avalikku kuulajat eraldi, seejärel vahendaja-taustaühendust vahendaja hostist ja alles siis klienti otsast lõpuni. Kõik need kolm testi välistavad erineva kihi. Ühe vahelejätmine tähendab, et kahte ülejäänud tulemust ei saa tõlgendada. Kolm tähelepanekut, kolm kohta, kus tõrge võib elada.

Hoidke sihtkoha aadress, port ja esimesed protokollibaidid iga tulemuse juures. See kolmik eristab serva viga VPN-i marsruutimise probleemist ja SSH autentimise tõrkest, ning see on vahe paranduse ja oletuse vahel.

Lõpuks dokumenteerige kavandatud kokkupuude. TCP-vahendaja, mis kannab SSH-d privaatsesse taustarakendusse, on teadlik avaus avalikus perimeetris ja väärib sama ülevaatamist nagu iga teine sissetulev teenus.

Seotud artiklid