SSH per NGINX srautų releją jo nesugriaunant

PROXY antraštė yra pranešimas tam, kas jos tikisi, o per tarpinį serverį publikuotas DNS įrašas nėra TCP relejus. Kraštą ir srautą prieš srovę taisykite atskirai.

Viešas SSH per releją žlunga dviejose nesusijusiose ribose, o vienos pataisymas dažniausiai atskleidžia kitą. Arba kraštas grąžina HTTP atsakymą vietoj srauto perdavimo, arba relejus priekyje įrašo antraštę, kurios fonas niekada nebuvo sutikęs skaityti. Trys sąlygos nulemia, kurią matote: į ką iš tikrųjų rodo viešas įrašas, ką srauto blokas siunčia prieš srovę ir kokį vardą tikrina SSH klientas. Tvarkykite jas šia tvarka.

Dvi ribos, du simptomai

Gedimas krašte atrodo kaip HTTP būsenos puslapis, atkeliaujantis ten, kur turėtų būti SSH baneris. Ryšys užbaigiamas TCP lygmenyje, o pirmieji baitai yra tekstas, priklausantis žiniatinklio serveriui. Tai protokolų neatitikimas, o ne prarastas paketas. Tai taip pat pasako, kad kraštas sąmoningai tam vardui teikia kažką kito.

Gedimas prieš srovę atrodo kitaip. Ryšys pasiekia sshd, sshd skaito baitus, kurie nėra laukiamas identifikavimo mainais, ir sesija miršta arba pakimba niekada nepasiūliusi rakto.

Abu lengva supainioti, nes abu sukuria klientą, kuris prisijungia ir tada žlunga. Pirmasis gautas protokolo atsakymas yra tai, kas juos atskiria, todėl jis ir priklauso bilietui.

PROXY antraštė yra pranešimas, o ne jungiklis

Srauto modulyje proxy_protocol on nurodo NGINX prieš naudingąją apkrovą į prieš srovę esančią pusę įrašyti PROXY protokolo antraštę. Tai neįjungia TCP tarpinio serverio ir neturi nieko bendra su SSH šifravimu. Tai gavėjui skirta pastaba. Jei gavėjas negali jos perskaityti, ji tampa šiukšlėmis srauto pradžioje.

Priimanti tarnyba turi sąmoningai suvartoti tą antraštę. Įprastas sshd tikisi SSH identifikavimo mainų kaip pirmųjų ryšio baitų, todėl netikėtas įžanginis įrašas sugriauna rankos paspaudimą taip, kad atrodo kaip sugadintas serveris.

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

Tas fragmentas yra visas veikiantis relejus fonui, pasiekiamam per VPN. Jokia PROXY direktyva nepasirodo, nes gavėjas nešneka tuo protokolu, ir šis nebuvimas yra sprendimas, o ne praleidimas.

Atskirkite ir abi kryptis. proxy_protocol nustatymas listen eilutėje reiškia, kad NGINX tikisi, jog jo paties klientas pirmiausia atsiųs antraštę; įjungus tai įprastam SSH klientui gaunamas lygiai priešingas problemos variantas, kurį žmonės paprastai bando išspręsti.

Ką iš tikrųjų pasiekia viešas pagrindinio kompiuterio vardas

HTTP 400 puslapis SSH sesijoje yra įrodymas apie kraštą. Kažkas kelyje kalba HTTP, ir joks raktų ar paskyros darbas fone to nepakeis. Nustokite keisti foną, kol kraštas nebus sutvarkytas.

Įprastas tarpinio serverio įrašas Cloudflare perduoda palaikomą HTTP ir HTTPS srautą nurodytais prievadais. Tarpinio serverio įjungimas pagrindinio kompiuterio vardui nesukuria bendro TCP relejaus, o SSH perkėlimas į 443 prievadą nepaverčia jo HTTPS.

Yra dvi įgyvendinamos kryptys. Tik DNS įrašas gali rodyti į jūsų pačių TCP relejų, o tai palieka poveikio sprendimą jūsų rankose. Arba naudokite produktą, kuris aiškiai dokumentuoja SSH perdavimą, su savo kilmės, kliento ir prieigos konfigūracija.

Kad ir ką pasirinktumėte, relejui vis dar reikia VPN maršruto į foną, leidžiamo ryšio ir grįžimo kelio. Maršrutas nėra pasirenkamas vien todėl, kad veikia viešoji pusė.

Išlaikykite SSH tapatybę stabilią naudodami slapyvardį

Naudotojai paprastai nori toliau rašyti savo esamą pagrindinio kompiuterio vardą. SSH konfigūracijos slapyvardis tai gali padaryti nieko relejuje nekeisdamas, ir palieka pakeitimą kliento pusėje, kur jam ir vieta.

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

Be HostKeyAlias OpenSSH ieško pagrindinio kompiuterio rakto pagal vardą, prie kurio jungiasi, todėl įrašas pasislenka ir kiekvienas naudotojas pirmą kartą pamato įspėjimą apie pasikeitusį raktą. Slapyvardžio nustatymas išlaiko known-hosts įrašus stabilius, o ryšys vis tiek eina į releją.

Šis slapyvardis galioja tik SSH pagrindu veikiantiems nuotoliniams saugykloms. HTTPS Git URL jo nesikonsultuoja, o įprastas nuotolinis URL turi atitikti tai, ką iš tikrųjų paruošėte.

Ko neturite daryti, tai išjungti pagrindinio kompiuterio rakto tikrinimą, kad išnyktų įspėjimas. Tai pašalina apsaugą, kurios perdavimo taisymas niekada neprašė liesti, ir paverčia kosmetinį nepatogumą tikru poveikiu.

Tikrinkite kiekvieną šuolį atskirai

Išbandykite viešą klausytoją atskirai, tada relejo ir fono ryšį iš relejo pagrindinio kompiuterio, ir tik po to klientą nuo galo iki galo. Kiekvienas iš tų trijų bandymų pašalina skirtingą sluoksnį. Praleidus vieną, likę du rezultatai negali būti interpretuojami. Trys stebėjimai, trys vietos, kur gali gyventi gedimas.

Išsaugokite paskirties adresą, prievadą ir pirmuosius protokolo baitus su kiekvienu rezultatu. Šis trejetas atskiria krašto klaidą nuo VPN maršrutizavimo problemos ir nuo SSH autentifikavimo gedimo, ir tai yra skirtumas tarp taisymo ir spėjimo.

Galiausiai dokumentuokite numatomą poveikį. TCP relejus, perduodantis SSH į privatų foną, yra sąmoningai atidaryta anga viešajame perimetre, ir jis nusipelno tokios pačios peržiūros kaip bet kuri kita įeinanti tarnyba.

Susiję straipsniai