SSH përmes një releje rryme NGINX pa e prishur

SSH publik përmes një releje dështon në dy kufij të palidhur, dhe rregullimi i njërit zakonisht zbulon tjetrin. Ose skaji kthen një përgjigje HTTP në vend që të transportojë një rrymë, ose releja shton përpara një kokë që backend-i nuk ka pranuar kurrë ta lexojë. Tre kushte përcaktojnë se cilin po shihni: ku tregon në të vërtetë regjistrimi publik, çfarë dërgon blloku i rrymës në rrjedhën e sipërme dhe cilin emër verifikon klienti SSH. Merreni me to në atë rend.

Dy kufij, dy simptoma

Një dështim në skaj duket si një faqe statusi HTTP që mbërrin atje ku duhet të ishte një banderolë SSH. Lidhja përfundon në nivelin TCP dhe bajtët e parë janë tekst që i përket një serveri web. Ky është një mospërputhje protokolli, jo një paketë e humbur. Ju tregon gjithashtu se skaji po shërben me dashje diçka tjetër për atë emër.

Një dështim në rrjedhën e sipërme duket ndryshe. Lidhja arrin sshd-në, sshd lexon bajtë që nuk janë shkëmbimi i identifikimit që pret, dhe sesioni vdes ose rri varur pa ofruar kurrë një çelës.

Të dyja ngatërrohen lehtë sepse të dyja prodhojnë një klient që lidhet dhe më pas dështon. Përgjigja e parë e protokollit që merrni është ajo që i dallon, prandaj i përket biletës.

Koka PROXY është një mesazh, jo një çelës ndërrimi

Në modulin e rrymës, proxy_protocol on i urdhëron NGINX-it të shkruajë përpara ngarkesës një kokë protokolli PROXY drejt rrjedhës së sipërme. Kjo nuk aktivizon proxy TCP dhe nuk ka lidhje me kriptimin SSH. Është një shënim drejtuar marrësit. Nëse marrësi nuk mund ta lexojë, ajo bëhet mbeturinë në fillim të rrymës.

Shërbimi marrës duhet ta konsumojë atë kokë me dashje. Një sshd normal pret shkëmbimin e identifikimit SSH si bajtët e parë të lidhjes, kështu që një parathënie e papritur e thyen shtrëngimin e duarve në një mënyrë që duket si server i korruptuar.

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

Ai fragment është tërë releja funksionale për një backend të arritshëm përmes VPN-së. Nuk shfaqet asnjë direktivë PROXY sepse marrësi nuk e flet atë protokoll, dhe ajo mungesë është vendim, jo lëshim.

Ndani edhe të dy drejtimet. Vendosja e proxy_protocol në rreshtin listen do të thotë që NGINX pret që klienti i vetë të dërgojë koken i pari; aktivizimi i tij për një klient SSH të zakonshëm prodhon saktësisht të kundërtën e problemit që njerëzit zakonisht përpiqen të zgjidhin.

Çfarë arrin në të vërtetë emri publik i hostit

Një faqe HTTP 400 në një sesion SSH është provë për skajin. Diçka në rrugë flet HTTP, dhe asnjë punë me çelës ose llogari në backend nuk do ta ndryshojë atë. Ndaloni ndryshimin e backend-it derisa skaji të jetë sqaruar.

Regjistrimi i zakonshëm i proxy-t i Cloudflare transporton trafikun e tij HTTP dhe HTTPS të mbështetur në porta të përcaktuara. Aktivizimi i proxy-t për një emër hosti nuk krijon një rele TCP të përgjithshme, dhe kalimi i SSH-së në portën 443 nuk e bën atë HTTPS.

Ekzistojnë dy drejtime të zbatueshme. Një regjistrim vetëm DNS mund të tregojë drejt relesë tuaj TCP, gjë që e lë vendimin për ekspozimin në duart tuaja. Përndryshe, përdorni një produkt që dokumenton shprehimisht transportin e SSH, me konfigurimin e vet të origjinës, klientit dhe qasjes.

Çfarëdo që të zgjidhni, relesë i duhet ende një rrugë VPN drejt backend-it, një lidhje e lejuar dhe një rrugë kthimi. Rruga nuk është fakultative sepse ana publike funksionon.

Mbani identitetin SSH të qëndrueshëm përmes një pseudonimi

Përdoruesit zakonisht duan të vazhdojnë të shkruajnë emrin e tyre ekzistues të hostit. Një pseudonim në konfigurimin e SSH mund ta bëjë këtë pa ndryshuar asgjë në rele, dhe e mban ndryshimin në anën e klientit, ku i takon.

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

Pa HostKeyAlias, OpenSSH e kërkon çelësin e hostit nën emrin me të cilin lidhet, kështu që zëri zhvendoset dhe çdo përdorues sheh një paralajmërim për çelës të ndryshuar në përdorimin e parë. Vendosja e pseudonimit i mban zërat e known-hosts të qëndrueshëm, ndërsa lidhja vazhdon të shkojë drejt relesë.

Ky pseudonim vlen vetëm për depo të largëta të bazuara në SSH. Një URL Git me HTTPS nuk e konsulton atë, dhe URL-ja tipike e largët duhet të përputhet me transportin që keni përgatitur në të vërtetë.

Ajo që nuk duhet të bëni është të çaktivizoni verifikimin e çelësit të hostit që paralajmërimi të zhduket. Kjo heq një mbrojtje që rregullimi i përcjelljes nuk ka kërkuar kurrë ta prekë, dhe e kthen një shqetësim kozmetik në një ekspozim të vërtetë.

Verifikoni çdo kërcim veçmas

Testoni dëgjuesin publik më vete, pastaj lidhjen rele-to-backend nga host-i i relesë, dhe vetëm pastaj klientin nga fillimi në fund. Secili nga ato tre teste përjashton një shtresë të ndryshme. Anashkalimi i njërit do të thotë që dy rezultatet e mbetura nuk mund të interpretohen. Tre vëzhgime, tre vende ku një dështim mund të jetojë.

Mbani adresën e destinacionit, portën dhe bajtët e parë të protokollit me çdo rezultat. Ky treshe dallon një gabim skaji nga një problem rrugëtimi VPN dhe nga një dështim vërtetimi SSH, dhe kjo është diferenca mes një rregullimi dhe një hamendjeje.

Së fundi, dokumentoni ekspozimin e synuar. Një rele TCP që çon SSH drejt një backend privat është një hapje e qëllimshme në perimetrin publik, dhe meriton të njëjtin shqyrtim si çdo shërbim tjetër hyrës.