SSH skozi prehod toka NGINX, ne da bi ga pokvarili

Glava PROXY je sporočilo za prejemnika, ki jo pričakuje, in posredovani zapis DNS ni prehod TCP. Popravite rob in nadrejeno stran ločeno.

Javni SSH skozi prehod odpove na dveh nepovezanih mejah, in popravilo ene običajno razkrije drugo. Bodisi rob vrne odgovor HTTP namesto prenašanja toka, bodisi prehod spredaj doda glavo, s katere branjem se zaledje ni nikoli strinjalo. Kateri primer vidite, določajo trije pogoji: na kaj javni zapis dejansko kaže, kaj blok toka pošilja navzgor in katero ime preveri odjemalec SSH. Ukvarjajte se z njimi v tem vrstnem redu.

Dve meji, dva simptoma

Napaka na robu je videti kot stran stanja HTTP, ki prispe tja, kjer bi moral biti pasica SSH. Povezava se zaključi na ravni TCP in prvi bajti so besedilo, ki pripada spletnemu strežniku. To je neujemanje protokola, ne izgubljen paket. Pove vam tudi, da rob za to ime namenoma streže nekaj drugega.

Napaka na nadrejeni strani je videti drugače. Povezava doseže sshd, sshd prebere bajte, ki niso pričakovana izmenjava identifikacije, in seja umre ali obvisi, ne da bi kdaj ponudila ključ.

Ta dva je lahko zamenjati, ker oba dajeta odjemalca, ki se poveže in nato odpove. Prvi prejeti odgovor protokola je tisto, kar ju loči, zato sodi v zahtevek.

Glava PROXY je sporočilo, ne stikalo

V modulu toka proxy_protocol on ukaže NGINX-u, da pred koristno obremenitvijo zapiše glavo protokola PROXY proti nadrejeni strani. To ne omogoči posredovanja TCP in nima nič skupnega s šifriranjem SSH. To je opomba, naslovljena na prejemnika. Če je prejemnik ne more prebrati, postane smeti na začetku toka.

Prejemna storitev mora to glavo zavestno porabiti. Običajen sshd pričakuje izmenjavo identifikacije SSH kot prve bajte povezave, zato nepričakovan predgovor pokvari rokovanje na način, ki je videti kot poškodovan strežnik.

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

Ta del je celoten delujoč prehod za zaledje, dosegljivo prek VPN. Ne pojavi se nobena direktiva PROXY, ker prejemnik ne govori tega protokola, in ta odsotnost je odločitev, ne izpustitev.

Ločite tudi obe smeri. Nastavitev proxy_protocol v vrstici listen pomeni, da NGINX pričakuje, da bo njegov lastni odjemalec glavo poslal prvi; če to omogočite za običajnega odjemalca SSH, dobite natanko nasprotno od težave, ki jo ljudje običajno poskušajo rešiti.

Kaj javno ime gostitelja dejansko doseže

Stran HTTP 400 v seji SSH je dokaz o robu. Nekaj na poti govori HTTP, in nobeno delo s ključem ali računom v zaledju tega ne bo spremenilo. Nehajte spreminjati zaledje, dokler rob ni urejen.

Običajen posredovani zapis Cloudflare prenaša podprt promet HTTP in HTTPS na določenih vratih. Vklop posrednika za ime gostitelja ne ustvari splošnega prehoda TCP, premik SSH na vrata 443 pa ga ne spremeni v HTTPS.

Obstajata dve izvedljivi smeri. Zapis samo z DNS lahko kaže na vaš lastni prehod TCP, kar odločitev o izpostavljenosti prepusti v vaše roke. Druga možnost je izdelek, ki izrecno dokumentira prenos SSH, z lastno konfiguracijo izvora, odjemalca in dostopa.

Karkoli izberete, prehod še vedno potrebuje pot VPN do zaledja, dovoljeno povezavo in povratno pot. Pot ni neobvezna zato, ker javna stran deluje.

Ohranite identiteto SSH stabilno z vzdevkom

Uporabniki običajno želijo še naprej tipkati svoje obstoječe ime gostitelja. Vzdevek v konfiguraciji SSH lahko to stori, ne da bi karkoli spremenil na prehodu, in spremembo ohrani na strani odjemalca, kamor sodi.

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

Brez HostKeyAlias OpenSSH išče ključ gostitelja pod imenom, s katerim se povezuje, zato se vnos premakne in vsak uporabnik ob prvi uporabi vidi opozorilo o spremenjenem ključu. Nastavitev vzdevka ohrani vnose known-hosts stabilne, medtem ko povezava še vedno poteka do prehoda.

Ta vzdevek velja le za oddaljene shrambe, ki temeljijo na SSH. URL Git prek HTTPS ga ne upošteva, in običajni oddaljeni URL se mora ujemati s prenosom, ki ste ga dejansko pripravili.

Česar ne smete storiti, je izklop preverjanja ključa gostitelja, da bi opozorilo izginilo. To odstrani zaščito, ki se je popravilo posredovanja ni nikoli prosilo, da bi se je dotaknilo, in kozmetično nadlogo spremeni v resnično izpostavljenost.

Preverite vsak skok posebej

Preizkusite javni poslušalec sam, nato povezavo od prehoda do zaledja z gostitelja prehoda in šele nato odjemalca od konca do konca. Vsak od teh treh preizkusov izključi drugo ravnino. Če enega izpustite, preostalih dveh rezultatov ni mogoče razložiti. Tri opažanja, tri mesta, kjer lahko živi napaka.

Ob vsakem rezultatu ohranite ciljni naslov, vrata in prve bajte protokola. Ta trojica loči napako roba od težave z usmerjanjem VPN in od neuspelega preverjanja pristnosti SSH, in to je razlika med popravilom in ugibanjem.

Na koncu dokumentirajte predvideno izpostavljenost. Prehod TCP, ki prenaša SSH do zasebnega zaledja, je namerna odprtina v javnem obsegu in si zasluži enak pregled kot katera koli druga vhodna storitev.

Sorodni članki