SSH caur NGINX straumes starpnieku to nesalaužot

Publiskais SSH caur starpnieku neizdodas divās nesaistītās robežās, un vienas labošana parasti atklāj otru. Vai nu mala atgriež HTTP atbildi, nevis pārraida straumi, vai starpnieks priekšā pievieno galveni, kuru aizmugure nekad nav piekritusi lasīt. Trīs nosacījumi nosaka, kuru jūs redzat: uz ko publiskais ieraksts patiešām norāda, ko straumes bloks sūta augšup un kuru vārdu pārbauda SSH klients. Apstrādājiet tos šajā secībā.

Divas robežas, divi simptomi

Kļūme malā izskatās kā HTTP statusa lapa, kas ierodas tur, kur jābūt SSH banerim. Savienojums pabeidzas TCP līmenī, un pirmie baiti ir teksts, kas pieder tīmekļa serverim. Tā ir protokola neatbilstība, nevis pazaudēts pakets. Tas arī pasaka, ka mala šim vārdam apzināti apkalpo kaut ko citu.

Kļūme augšupējā izskatās citādi. Savienojums sasniedz sshd, sshd nolasa baitus, kas nav gaidītā identifikācijas apmaiņa, un sesija mirst vai iekaras, nekad nepiedāvājot atslēgu.

Abus var viegli sajaukt, jo abi rada klientu, kas savienojas un pēc tam neizdodas. Pirmā saņemtā protokola atbilde ir tas, kas tos atšķir, un tāpēc tā pieder biļetei.

PROXY galvene ir ziņojums, nevis slēdzis

Straumes modulī proxy_protocol on liek NGINX pirms lietderīgās slodzes rakstīt PROXY protokola galveni virzienā uz augšupēju. Tas neieslēdz TCP starpniecību, un tam nav nekāda sakara ar SSH šifrēšanu. Tas ir saņēmējam adresēta piezīme. Ja saņēmējs to nevar nolasīt, tā kļūst par atkritumiem straumes sākumā.

Saņēmējam pakalpojumam šī galvene ir apzināti jāpatērē. Parasts sshd gaida SSH identifikācijas apmaiņu kā savienojuma pirmos baitus, tāpēc negaidīta ievadfrāze salauž rokasspiedienu tā, ka tas izskatās pēc bojāta servera.

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

Šis fragments ir viss strādājošais starpnieks aizmugurei, kas sasniedzama caur VPN. Nekāda PROXY direktīva neparādās, jo saņēmējs nerunā šajā protokolā, un šī neesamība ir lēmums, nevis izlaidums.

Atdaliet arī abus virzienus. proxy_protocol iestatīšana listen rindā nozīmē, ka NGINX gaida, ka tā paša klients vispirms nosūtīs galveni; ieslēdzot to parastam SSH klientam, tiek iegūts tieši pretējais problēmai, ko cilvēki parasti cenšas atrisināt.

Ko publiskais resursdatora nosaukums patiešām sasniedz

HTTP 400 lapa SSH sesijā ir pierādījums par malu. Kaut kas ceļā runā HTTP, un nekāds atslēgas vai konta darbs aizmugurē to nemainīs. Pārtrauciet mainīt aizmuguri, līdz mala ir sakārtota.

Parastais starpniekotais Cloudflare ieraksts pārvadā atbalstīto HTTP un HTTPS datplūsmu noteiktos portos. Starpnieka ieslēgšana resursdatora nosaukumam nerada vispārīgu TCP starpnieku, un SSH pārvietošana uz portu 443 nepadara to par HTTPS.

Pastāv divi īstenojami virzieni. Tikai DNS ieraksts var norādīt uz jūsu pašu TCP starpnieku, kas atstāj iedarbības lēmumu jūsu rokās. Vai arī izmantojiet produktu, kas skaidri dokumentē SSH pārvadi, ar savu izcelsmes, klienta un piekļuves konfigurāciju.

Lai ko jūs izvēlētos, starpniekam joprojām vajag VPN maršrutu uz aizmuguri, atļautu savienojumu un atgriešanās ceļu. Maršruts nav izvēles iespēja, jo publiskā puse darbojas.

Saglabājiet SSH identitāti stabilu ar aizstājvārdu

Lietotāji parasti vēlas turpināt rakstīt savu esošo resursdatora nosaukumu. SSH konfigurācijas aizstājvārds to var izdarīt, neko starpniekā nemainot, un tas atstāj izmaiņas klienta pusē, kur tām ir vieta.

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

Bez HostKeyAlias OpenSSH meklē resursdatora atslēgu zem nosaukuma, ar kuru tas savienojas, tāpēc ieraksts pārvietojas, un katrs lietotājs pirmajā lietošanā redz brīdinājumu par mainītu atslēgu. Aizstājvārda iestatīšana saglabā known-hosts ierakstus stabilus, kamēr savienojums joprojām iet uz starpnieku.

Šis aizstājvārds attiecas tikai uz SSH balstītām attālinātām krātuvēm. HTTPS Git URL to neizmanto, un tipiskais attālinātais URL ir jāsaskaņo ar pārvadi, kuru jūs patiešām nodrošinājāt.

Tas, ko jums nevajadzētu darīt, ir izslēgt resursdatora atslēgas pārbaudi, lai brīdinājums pazustu. Tas noņem aizsardzību, kurai pāradresācijas labojums nekad nav lūdzis pieskarties, un pārvērš kosmētisku neērtību īstā iedarbībā.

Pārbaudiet katru lēcienu atsevišķi

Pārbaudiet publisko klausītāju atsevišķi, tad starpnieka un aizmugures savienojumu no starpnieka resursdatora, un tikai pēc tam klientu no gala līdz galam. Ikviens no šiem trim testiem izslēdz citu slāni. Viena izlaišana nozīmē, ka atlikušos divus rezultātus nevar interpretēt. Trīs novērojumi, trīs vietas, kur kļūme var dzīvot.

Saglabājiet galamērķa adresi, portu un pirmos protokola baitus kopā ar katru rezultātu. Šis trijnieks atšķir malas kļūdu no VPN maršrutēšanas problēmas un no SSH autentifikācijas kļūmes, un tā ir atšķirība starp labojumu un minējumu.

Visbeidzot, dokumentējiet paredzēto iedarbību. TCP starpnieks, kas pārvada SSH uz privātu aizmuguri, ir apzināti atvērts logs publiskajā perimetrā, un tas ir pelnījis tādu pašu pārskatīšanu kā jebkurš cits ienākošais pakalpojums.