SSH printr-un releu de flux NGINX fără a-l strica

Un antet PROXY este un mesaj pentru un receptor care îl așteaptă, iar o înregistrare DNS cu proxy nu este un releu TCP. Remediați marginea și sursa separat.

SSH public printr-un releu eșuează la două granițe fără legătură, iar repararea uneia o dezvăluie de obicei pe cealaltă. Fie marginea returnează un răspuns HTTP în loc să transporte un flux, fie releul adaugă în față un antet pe care backendul nu a fost niciodată de acord să îl citească. Trei condiții decid pe care dintre ele îl vedeți: spre ce indică de fapt înregistrarea publică, ce trimite blocul de flux spre amonte și ce nume verifică clientul SSH. Tratați-le în această ordine.

Două granițe, două simptome

O defecțiune la margine arată ca o pagină de stare HTTP care ajunge acolo unde ar trebui să fie un banner SSH. Conexiunea se încheie la nivel TCP, iar primii octeți sunt text care aparține unui server web. Este o nepotrivire de protocol, nu un pachet pierdut. Vă mai spune și că marginea servește în mod deliberat altceva pentru acel nume.

O defecțiune la amonte arată altfel. Conexiunea ajunge la sshd, sshd citește octeți care nu sunt schimbul de identificare așteptat, iar sesiunea moare sau se blochează fără a oferi vreodată o cheie.

Cele două se confundă ușor pentru că ambele produc un client care se conectează și apoi eșuează. Primul răspuns de protocol pe care îl primiți este cel care le distinge, de aceea îi aparține biletului.

Antetul PROXY este un mesaj, nu un comutator

În modulul de flux, proxy_protocol on îi cere NGINX să scrie un antet de protocol PROXY spre amonte înainte de payload. Nu activează proxy-ul TCP și nu are nimic de-a face cu criptarea SSH. Este o notă adresată receptorului. Dacă receptorul nu o poate citi, devine resturi la începutul fluxului.

Serviciul receptor trebuie să consume acel antet în mod deliberat. Un sshd normal așteaptă schimbul de identificare SSH ca primii octeți ai conexiunii, așa că un preambul neașteptat rupe strângerea de mână într-un mod care arată ca un server corupt.

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

Acest fragment este întregul releu funcțional pentru un backend accesibil prin VPN. Nu apare nicio directivă PROXY pentru că receptorul nu vorbește protocolul, iar acea absență este o decizie, nu o omisiune.

Separați și cele două direcții. Setarea proxy_protocol pe linia listen înseamnă că NGINX așteaptă ca propriul client să trimită antetul primul; activarea pentru un client SSH obișnuit produce exact opusul problemei pe care oamenii încearcă de obicei să o rezolve.

Ce ajunge de fapt numele de gazdă public

O pagină HTTP 400 într-o sesiune SSH este o dovadă despre margine. Ceva de pe traseu vorbește HTTP, iar nicio muncă la cheie sau cont pe backend nu va schimba asta. Opriți modificarea backendului până când marginea este lămurită.

Înregistrarea cu proxy obișnuită a Cloudflare transportă traficul HTTP și HTTPS acceptat pe porturi definite. Activarea proxy-ului pentru un nume de gazdă nu creează un releu TCP general, iar mutarea SSH pe portul 443 nu îl face HTTPS.

Există două direcții viabile. O înregistrare doar DNS poate indica propriul releu TCP, ceea ce lasă decizia despre expunere în mâinile dumneavoastră. Alternativ, folosiți un produs care documentează explicit transportul SSH, cu propria configurare de origine, client și acces.

Orice ați alege, releul are în continuare nevoie de o rută VPN către backend, de o conexiune permisă și de o cale de întoarcere. Ruta nu este opțională pentru că partea publică funcționează.

Păstrați identitatea SSH stabilă printr-un alias

Utilizatorii vor de obicei să continue să tasteze numele de gazdă existent. Un alias în configurația SSH poate face asta fără a schimba nimic la releu și păstrează modificarea pe partea clientului, unde îi este locul.

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

Fără HostKeyAlias, OpenSSH caută cheia gazdei sub numele la care se conectează, așa că intrarea se mută și fiecare utilizator vede un avertisment de cheie schimbată la prima utilizare. Setarea aliasului păstrează stabile intrările din known-hosts în timp ce conexiunea merge în continuare la releu.

Acest alias se aplică doar depozitelor la distanță bazate pe SSH. Un URL Git prin HTTPS nu îl consultă, iar URL-ul tipic al depozitului la distanță trebuie să corespundă transportului pe care l-ați pregătit efectiv.

Ce nu trebuie să faceți este să dezactivați verificarea cheii gazdei pentru ca avertismentul să dispară. Asta înlătură o protecție pe care reparația redirecționării nu a cerut niciodată să o atingă și transformă o neplăcere estetică într-o expunere reală.

Verificați fiecare salt separat

Testați ascultătorul public singur, apoi conexiunea de la releu la backend de pe gazda releului și abia apoi clientul de la un capăt la altul. Fiecare dintre cele trei teste exclude un strat diferit. Sărirea peste unul înseamnă că celelalte două rezultate nu pot fi interpretate. Trei observații, trei locuri unde poate trăi o defecțiune.

Păstrați adresa de destinație, portul și primii octeți de protocol împreună cu fiecare rezultat. Acel trio distinge o eroare de margine de o problemă de rutare VPN și de o defecțiune de autentificare SSH, iar aceasta este diferența dintre o reparație și o presupunere.

În final, documentați expunerea intenționată. Un releu TCP care transportă SSH către un backend privat este o deschidere deliberată în perimetrul public și merită aceeași revizuire ca orice alt serviciu de intrare.

Articole similare