SSH gjennom eit NGINX-straumrelé utan å øydeleggje det

Ein PROXY-header er ei melding til ein mottakar som ventar han, og ein proxy-a DNS-post er ikkje eit TCP-relé. Fiks kanten og oppstraums kvar for seg.

Offentleg SSH gjennom eit relé feilar ved to uavhengige grenser, og å fikse den eine avdekkjer vanlegvis den andre. Anten returnerer kanten eit HTTP-svar i staden for å føre ein straum, eller reléet set ein header framom som backend aldri har samtykt i å lese. Tre tilhøve avgjer kva du ser: kva den offentlege posten faktisk peikar på, kva straumblokka sender oppstraums, og kva namn SSH-klienten stadfester. Arbeid deg gjennom dei i den rekkjefølgja.

To grenser, to symptom

Ein feil ved kanten ser ut som ei HTTP-statusside som kjem der ein SSH-banner skulle vore. Sambandet blir fullført på TCP-nivå, og dei første byta er tekst som høyrer til ein webserver. Det er eit protokollavvik, ikkje ein tapt pakke. Det fortel deg òg at kanten med vilje tener noko anna for det namnet.

Ein feil oppstraums ser annleis ut. Sambandet når sshd, sshd les byt som ikkje er identifikasjonsutvekslinga det ventar, og økta døyr eller heng utan å nokosinne tilby ein nøkkel.

Dei to er lette å forveksle fordi begge gjev ein klient som koplar til og deretter feilar. Det første protokollsvar du mottek er det som skil dei, og difor høyrer det heime i saka.

PROXY-headeren er ei melding, ikkje ein brytar

I straummodulen instruerer proxy_protocol on NGINX i å skrive ein PROXY-protokollheader mot oppstraums før nyttelasta. Det slår ikkje på TCP-proxy, og det har ingenting med SSH-kryptering å gjere. Det er eit notat retta til mottakaren. Om mottakaren ikkje kan lese det, blir det søppel i starten av straumen.

Den mottakande tenesta må med vilje konsumere den headeren. Ein vanleg sshd ventar SSH-identifikasjonsutvekslinga som dei første byta på sambandet, så ei uventa innleiing øydelegg handtrykket på ein måte som ser ut som ein skadd server.

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

Det fragmentet er heile eit fungerande relé for ein backend som er tilgjengeleg over VPN-en. Det viser seg ingen PROXY-direktiv fordi mottakaren ikkje snakkar protokollen, og den fråværet er eit val, ikkje ei utelating.

Skil òg dei to retningane. Å setje proxy_protocol på listen-linja betyr at NGINX ventar at sin eigen klient sender headeren først; å slå det på for ein vanleg SSH-klient gjev nøyaktig det motsette av problemet folk vanlegvis prøver å løyse.

Kva det offentlege vertsnamnet faktisk når

Ei HTTP 400-side i ei SSH-økt er prov om kanten. Noko på vegen snakkar HTTP, og inga nøkkel- eller kontohandtering på backend vil endre det. Slutt å endre backend til kanten er avklara.

Den vanlege proxy-a posten til Cloudflare ber sin støtta HTTP- og HTTPS-trafikk på definerte portar. Å slå på proxyen for eit vertsnamn skaper ikkje eit generelt TCP-relé, og å flytte SSH til port 443 gjer det ikkje til HTTPS.

Det finst to brukbare retningar. Ein DNS-berre post kan peike på ditt eige TCP-relé, noko som legg avgjerda om eksponering i hendene dine. Alternativt kan du bruke eit produkt som eksplisitt dokumenterer SSH-transport, med si eiga origin-, klient- og tilgangskonfigurasjon.

Uansett kva du vel, treng reléet framleis ei VPN-rute til backend, eit tillaten samband og ein returveg. Ruta er ikkje valfri fordi den offentlege sida verkar.

Hald SSH-identiteten stabil gjennom eit alias

Brukarar vil vanlegvis halde fram med å skrive det eksisterande vertsnamnet sitt. Eit alias i SSH-konfigurasjonen kan gjere det utan å endre noko ved reléet, og det held endringa på klientsida der ho høyrer heime.

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

Utan HostKeyAlias slår OpenSSH opp vertsnøkkelen under namnet det koplar til, så oppføringa flyttar seg og kvar brukar ser ei åtvaring om endra nøkkel ved første bruk. Å setje aliaset held known-hosts-oppføringar stabile medan sambandet framleis går til reléet.

Dette aliaset gjeld berre for SSH-baserte fjernlager. Ein HTTPS-Git-URL konsulterer det ikkje, og den typiske fjern-URL-en må svare til transporten du faktisk har etablert.

Det du ikkje må gjere, er å slå av vertsnøkkelstadfesting for å bli kvitt åtvaringa. Det fjernar ei vern som videresendingsreparasjonen aldri bad om å røre, og det gjer ein kosmetisk irritasjon til ein reell eksponering.

Stadfest kvart hopp separat

Test den offentlege lyttaren åleine, deretter relé-til-backend-sambandet frå reléverten, og først då klienten ende til ende. Kvar av dei tre testane utelukkar eit ulikt lag. Blir ein hoppa over, tyder det at dei to gjenverande resultata ikkje kan tolkast. Tre observasjonar, tre stader der ein feil kan bu.

Ta vare på måladdressa, porten og dei første protokollbyta saman med kvart resultat. Den trioen skil ein kantfeil frå eit VPN-rutingproblem frå ein SSH-autentiseringsfeil, og det er skilnaden mellom ein reparasjon og ei gissing.

Til slutt, dokumenter den tilsikta eksponeringa. Eit TCP-relé som fører SSH til ein privat backend er ei medvite opning i den offentlege periferien, og det fortener same gjennomgang som kvar annan inngåande teneste.

Relaterte artiklar