SSH sa pamamagitan ng NGINX stream relay nang hindi ito sinisira

Ang pampublikong SSH sa pamamagitan ng relay ay nabibigo sa dalawang magkaibang hangganan, at ang pag-aayos ng isa ay karaniwang naglalantad ng isa pa. Alinman sa gilid ay nagbabalik ng HTTP response sa halip na maghatid ng stream, o ang relay ay naglalagay sa unahan ng header na hindi kailanman sinang-ayunan ng backend na basahin. Tatlong kundisyon ang nagtatakda kung alin ang nakikita mo: kung saan talaga nakaturo ang pampublikong record, ano ang ipinapadala ng stream block pataas, at aling pangalan ang tinitiyak ng SSH client. Harapin ang mga ito sa ganoong pagkakasunod-sunod.

Dalawang hangganan, dalawang sintomas

Ang kabiguan sa gilid ay mukhang pahina ng HTTP status na dumarating kung saan dapat may SSH banner. Nakumpleto ang koneksyon sa antas ng TCP at ang mga unang byte ay teksto na pag-aari ng web server. Iyon ay hindi pagkakatugma ng protocol, hindi nawalang packet. Sinasabi rin nito na sadyang naghahain ang gilid ng ibang bagay para sa pangalang iyon.

Ang kabiguan sa upstream ay iba ang hitsura. Naabot ng koneksyon ang sshd, binabasa ng sshd ang mga byte na hindi ang inaasahang pagpapalitan ng pagkakakilanlan, at namamatay o bumabitin ang session nang hindi kailanman nag-aalok ng key.

Madaling mapagkamalan ang dalawa dahil parehong gumagawa ng client na kumokonekta at pagkatapos ay nabibigo. Ang unang protocol response na natatanggap mo ang nagtatangi sa kanila, kaya nararapat itong nasa ticket.

Ang PROXY header ay mensahe, hindi switch

Sa stream module, inuutusan ng proxy_protocol on ang NGINX na magsulat ng PROXY protocol header patungo sa upstream bago ang payload. Hindi nito pinapagana ang TCP proxy, at wala itong kinalaman sa SSH encryption. Ito ay tala na nakatuon sa tatanggap. Kung hindi ito mabasa ng tatanggap, nagiging basura ito sa simula ng stream.

Dapat sadyang gamitin ng tumatanggap na serbisyo ang header na iyon. Ang normal na sshd ay umaasa sa SSH identification exchange bilang mga unang byte ng koneksyon, kaya ang hindi inaasahang paunang salita ay sumisira sa handshake sa paraang mukhang sirang server.

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

Ang pirasong iyon ay ang buong gumaganang relay para sa backend na maabot sa pamamagitan ng VPN. Walang direktibang PROXY na lumilitaw dahil hindi nagsasalita ng protocol na iyon ang tatanggap, at ang kawalan na iyon ay desisyon, hindi pagpapabaya.

Paghiwalayin din ang dalawang direksyon. Ang pagtatakda ng proxy_protocol sa linyang listen ay nangangahulugang inaasahan ng NGINX na ang sarili nitong client ang unang magpapadala ng header; ang pagpapagana nito para sa ordinaryong SSH client ay gumagawa ng eksaktong kabaligtaran ng problemang karaniwang sinusubukang lutasin ng mga tao.

Ano ang talagang naaabot ng pampublikong hostname

Ang pahinang HTTP 400 sa isang SSH session ay ebidensya tungkol sa gilid. May nagsasalita ng HTTP sa landas, at walang gawaing key o account sa backend ang makakapagpabago niyon. Itigil ang pagbabago ng backend hanggang sa maayos ang gilid.

Ang ordinaryong na-proxy na record ng Cloudflare ay nagdadala ng sinusuportahang HTTP at HTTPS traffic nito sa mga tinukoy na port. Ang pagbukas ng proxy para sa isang hostname ay hindi gumagawa ng pangkalahatang TCP relay, at ang paglipat ng SSH sa port 443 ay hindi ito ginagawang HTTPS.

May dalawang magagawang direksyon. Ang record na DNS lamang ay maaaring tumuro sa sarili mong TCP relay, na naglalagay ng desisyon tungkol sa paghahayag sa iyong mga kamay. Bilang kahalili, gumamit ng produktong tahasang nagdodokumento ng SSH carriage, kasama ang sarili nitong origin, client at access configuration.

Anuman ang piliin mo, kailangan pa rin ng relay ng VPN route patungo sa backend, pinahihintulutang koneksyon at daan pabalik. Ang ruta ay hindi opsyonal dahil gumagana ang pampublikong bahagi.

Panatilihing matatag ang pagkakakilanlang SSH sa pamamagitan ng alias

Karaniwang gustong ipagpatuloy ng mga user ang pagta-type ng kanilang umiiral na hostname. Maaaring gawin ito ng alias sa SSH configuration nang walang binabago sa relay, at pinapanatili nito ang pagbabago sa panig ng client kung saan nararapat.

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

Kung walang HostKeyAlias, hinahanap ng OpenSSH ang host key sa ilalim ng pangalang kinokonektahan nito, kaya gumagalaw ang entry at nakikita ng bawat user ang babala tungkol sa nabagong key sa unang paggamit. Ang pagtatakda ng alias ay nagpapanatili ng mga entry sa known-hosts na matatag habang ang koneksyon ay patungo pa rin sa relay.

Ang alias na ito ay nalalapat lamang sa mga remote na nakabatay sa SSH. Ang HTTPS Git URL ay hindi sumasangguni rito, at ang karaniwang remote URL ay dapat tumugma sa transport na aktuwal mong inihanda.

Ang hindi mo dapat gawin ay patayin ang pagpapatunay ng host key upang mawala ang babala. Inaalis niyon ang proteksyong hindi kailanman hiniling ng pag-aayos ng forwarding na galawin, at ginagawang tunay na paghahayag ang isang kosmetikong abala.

Tiyakin ang bawat hop nang hiwalay

Subukan ang pampublikong listener nang mag-isa, pagkatapos ang koneksyon mula sa relay patungo sa backend mula sa relay host, at pagkatapos lamang ang client mula simula hanggang dulo. Ang bawat isa sa tatlong pagsubok ay nag-aalis ng ibang antas. Ang paglaktaw ng isa ay nangangahulugang hindi maipaliwanag ang natitirang dalawang resulta. Tatlong obserbasyon, tatlong lugar kung saan maaaring manirahan ang kabiguan.

Itabi ang patutunguhang address, port at mga unang protocol byte kasama ng bawat resulta. Ang triplet na iyon ay nagtatangi ng error sa gilid mula sa problema sa VPN routing at mula sa kabiguan ng SSH authentication, at iyon ang pagkakaiba ng pag-aayos at haka-haka.

Panghuli, idokumento ang inaasahang paghahayag. Ang TCP relay na nagdadala ng SSH patungo sa pribadong backend ay sadyang pagbubukas sa pampublikong perimeter, at karapat-dapat ito sa parehong pagsusuri gaya ng anumang iba pang papasok na serbisyo.