SSH kupitia kirudishi cha mtiririko cha NGINX bila kuivunja

Kichwa cha PROXY ni ujumbe kwa mpokeaji anayeutarajia, na rekodi ya DNS iliyopitishwa na proksi si kirudishi cha TCP. Rekebisha ukingo na mkondo wa juu kando kando.

SSH ya umma kupitia kirudishi hushindwa katika mipaka miwili isiyohusiana, na kurekebisha mmoja kwa kawaida hufichua mwingine. Ama ukingo hurudisha jibu la HTTP badala ya kubeba mtiririko, au kirudishi huweka kichwa mbele ambacho backend haikukubali kamwe kusoma. Masharti matatu huamua unachokiona: rekodi ya umma inaelekeza wapi kwa kweli, kizuizi cha mtiririko hutuma nini juu, na jina gani mteja wa SSH huthibitisha. Shughulikia kwa mpangilio huo.

Mipaka miwili, dalili mbili

Kushindwa kwa ukingo huonekana kama ukurasa wa hali ya HTTP unaofika mahali ambapo bango la SSH linapaswa kuwa. Muunganisho hukamilika katika ngazi ya TCP na baiti za kwanza ni maandishi ya seva ya wavuti. Hiyo ni kutokubaliana kwa itifaki, si pakiti iliyopotea. Pia hukuambia kwamba ukingo unahudumia kitu kingine kwa makusudi kwa jina hilo.

Kushindwa kwa mkondo wa juu huonekana tofauti. Muunganisho hufikia sshd, sshd husoma baiti ambazo si ubadilishanaji wa utambulisho unaotarajiwa, na kikao hufa au huning'inia bila kutoa ufunguo kamwe.

Hizi mbili ni rahisi kuchanganya kwa sababu zote hutoa mteja anayeunganisha na kisha kushindwa. Jibu la kwanza la itifaki unalopokea ndilo linalozitofautisha, ndiyo maana linapaswa kuwa kwenye tiketi.

Kichwa cha PROXY ni ujumbe, si swichi

Katika moduli ya mtiririko, proxy_protocol on huagiza NGINX kuandika kichwa cha itifaki ya PROXY kuelekea mkondo wa juu kabla ya mzigo. Hii haiwezeshi proksi ya TCP, na haihusiani kabisa na usimbaji fiche wa SSH. Ni dokezo linaloelekezwa kwa mpokeaji. Ikiwa mpokeaji hawezi kulisoma, linakuwa taka mwanzoni mwa mtiririko.

Huduma inayopokea lazima itumie kichwa hicho kwa makusudi. sshd ya kawaida hutarajia ubadilishanaji wa utambulisho wa SSH kama baiti za kwanza kwenye muunganisho, kwa hiyo utangulizi usiotarajiwa huvunja kupeana mikono kwa namna inayoonekana kama seva iliyoharibika.

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

Kipande hicho ni kirudishi kizima kinachofanya kazi kwa backend inayofikiwa kupitia VPN. Hakuna agizo la PROXY linaloonekana kwa sababu mpokeaji hazungumzi itifaki hiyo, na ukosefu huo ni uamuzi, si upungufu.

Tenganisha pia mielekeo miwili. Kuweka proxy_protocol kwenye mstari wa listen kunamaanisha NGINX inatarajia mteja wake mwenyewe atume kichwa kwanza; kuiwezesha kwa mteja wa kawaida wa SSH huzalisha kinyume kabisa cha tatizo ambalo watu kwa kawaida hujaribu kulitatua.

Jina la mwenyeji la umma hufikia nini kwa kweli

Ukurasa wa HTTP 400 katika kikao cha SSH ni ushahidi kuhusu ukingo. Kitu fulani kwenye njia huzungumza HTTP, na hakuna kazi yoyote ya ufunguo au akaunti kwenye backend itakayobadilisha hilo. Acha kubadilisha backend hadi ukingo utakapotatuliwa.

Rekodi ya kawaida ya Cloudflare iliyopitishwa na proksi hubeba trafiki yake ya HTTP na HTTPS inayotumika kwenye bandari zilizoainishwa. Kuwasha proksi kwa jina la mwenyeji hakuundi kirudishi cha jumla cha TCP, na kuhamisha SSH hadi bandari 443 hakukifanyi kuwa HTTPS.

Kuna mielekeo miwili inayoweza kufanyika. Rekodi ya DNS pekee inaweza kuelekeza kwenye kirudishi chako mwenyewe cha TCP, ambayo huweka uamuzi wa uwekaji wazi mikononi mwako. Vinginevyo, tumia bidhaa inayoandika wazi usafirishaji wa SSH, pamoja na usanidi wake wa asili, mteja na ufikiaji.

Chochote utakachochagua, kirudishi bado kinahitaji njia ya VPN hadi backend, muunganisho unaoruhusiwa na njia ya kurudi. Njia hiyo si ya hiari kwa sababu upande wa umma unafanya kazi.

Weka utambulisho wa SSH thabiti kupitia jina bandia

Watumiaji kwa kawaida hutaka kuendelea kuandika jina lao la sasa la mwenyeji. Jina bandia katika usanidi wa SSH linaweza kufanya hivyo bila kubadilisha chochote kwenye kirudishi, na huweka mabadiliko upande wa mteja ambapo yanapaswa kuwa.

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

Bila HostKeyAlias, OpenSSH hutafuta ufunguo wa mwenyeji chini ya jina analounganisha nalo, kwa hiyo ingizo huhamia na kila mtumiaji huona onyo la ufunguo uliobadilika katika matumizi ya kwanza. Kuweka jina bandia huweka maingizo ya known-hosts thabiti wakati muunganisho bado unaenda kwenye kirudishi.

Jina bandia hili linatumika kwa hazina za mbali zinazotegemea SSH pekee. URL ya Git ya HTTPS haizingatii hilo, na URL ya kawaida ya mbali lazima ilingane na usafirishaji uliouandaa kwa kweli.

Usichopaswa kufanya ni kuzima uthibitishaji wa ufunguo wa mwenyeji ili onyo liondoke. Hiyo huondoa ulinzi ambao urekebishaji wa uelekezaji haukuomba kamwe kuugusa, na hugeuza usumbufu wa mwonekano kuwa uwekaji wazi halisi.

Thibitisha kila hatua kando

Jaribu kisikilizaji cha umma kikiwa peke yake, kisha muunganisho wa kirudishi-hadi-backend kutoka kwa mwenyeji wa kirudishi, na hapo ndipo tu mteja kutoka mwanzo hadi mwisho. Kila moja ya majaribio hayo matatu huondoa tabaka tofauti. Kuruka moja kunamaanisha matokeo mawili yaliyobaki hayawezi kufasiriwa. Uchunguzi matatu, sehemu tatu ambazo kushindwa kunaweza kuishi.

Hifadhi anwani ya lengo, bandari na baiti za kwanza za itifaki pamoja na kila matokeo. Utatu huo hutofautisha hitilafu ya ukingo na tatizo la uelekezaji wa VPN na kushindwa kwa uthibitishaji wa SSH, na hiyo ni tofauti kati ya urekebishaji na dhana.

Hatimaye, andika uwekaji wazi uliokusudiwa. Kirudishi cha TCP kinachobeba SSH hadi backend ya kibinafsi ni ufunguzi wa makusudi katika mzunguko wa umma, na kinastahili mapitio sawa na huduma nyingine yoyote inayoingia.

Makala zinazohusiana