SSH gjennom et NGINX-strømrelé uten å ødelegge det

En PROXY-header er en melding til en mottaker som forventer den, og en proxyet DNS-post er ikke et TCP-relé. Fiks kanten og oppstrøms hver for seg.

Offentlig SSH gjennom et relé feiler ved to uavhengige grenser, og å fikse den ene avdekker vanligvis den andre. Enten returnerer kanten et HTTP-svar i stedet for å føre en strøm, eller reléet setter en header foran som backend aldri har samtykket i å lese. Tre forhold avgjør hvilken du ser: hva den offentlige posten faktisk peker på, hva strømblokken sender oppstrøms, og hvilket navn SSH-klienten verifiserer. Arbeid deg gjennom dem i den rekkefølgen.

To grenser, to symptomer

En feil ved kanten ser ut som en HTTP-statusside som ankommer der en SSH-banner skulle vært. Forbindelsen fullføres på TCP-nivå, og de første bytene er tekst som tilhører en webserver. Det er en protokollavvik, ikke en tapt pakke. Det forteller deg også at kanten bevisst betjener noe annet for det navnet.

En feil oppstrøms ser annerledes ut. Forbindelsen når sshd, sshd leser byte som ikke er identifikasjonsutvekslingen den forventer, og økten dør eller henger uten å noensinne tilby en nøkkel.

De to er lette å forveksle fordi begge gir en klient som kobler til og deretter feiler. Det første protokollsvar du mottar er det som skiller dem, og derfor hører det hjemme i saken.

PROXY-headeren er en melding, ikke en bryter

I strømmodulen instruerer proxy_protocol on NGINX i å skrive en PROXY-protokollheader mot oppstrøms før nyttelasten. Det aktiverer ikke TCP-proxy, og det har ingenting med SSH-kryptering å gjøre. Det er et notat rettet til mottakeren. Hvis mottakeren ikke kan lese det, blir det søppel i starten av strømmen.

Den mottakende tjenesten må bevisst konsumere den headeren. En vanlig sshd forventer SSH-identifikasjonsutvekslingen som de første bytene på forbindelsen, så en uventet innledning ødelegger håndtrykket på en måte som ser ut som en skadet server.

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

Det fragmentet er hele et fungerende relé for en backend som er tilgjengelig over VPN-en. Det vises ingen PROXY-direktiv fordi mottakeren ikke snakker protokollen, og den fraværet er et valg, ikke en utelatelse.

Skill også de to retningene. Å sette proxy_protocol på listen-linjen betyr at NGINX forventer at dens egen klient sender headeren først; å aktivere det for en vanlig SSH-klient gir nøyaktig det motsatte av problemet folk vanligvis prøver å løse.

Hva det offentlige vertsnavnet faktisk når

En HTTP 400-side i en SSH-økt er bevis om kanten. Noe på veien snakker HTTP, og ingen nøkkel- eller kontohandling på backend vil endre det. Slutt å endre backend til kanten er avklart.

Den vanlige proxyede posten til Cloudflare bærer sin støttede HTTP- og HTTPS-trafikk på definerte porter. Å slå på proxyen for et vertsnavn skaper ikke et generelt TCP-relé, og å flytte SSH til port 443 gjør det ikke til HTTPS.

Det finnes to brukbare retninger. En DNS-bare post kan peke på ditt eget TCP-relé, noe som legger beslutningen om eksponering i dine hender. Alternativt kan du bruke et produkt som eksplisitt dokumenterer SSH-transport, med sin egen origin-, klient- og tilgangskonfigurasjon.

Uansett hva du velger, trenger reléet fortsatt en VPN-rute til backend, en tillatt forbindelse og en returvei. Ruten er ikke valgfri fordi den offentlige siden virker.

Hold SSH-identiteten stabil gjennom et alias

Brukere vil vanligvis fortsette å skrive det eksisterende vertsnavnet sitt. Et alias i SSH-konfigurasjonen kan gjøre det uten å endre noe ved reléet, og det holder endringen på klientsiden der den hører hjemme.

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

Uten HostKeyAlias slår OpenSSH opp vertsnøkkelen under navnet den kobler til, så oppføringen flytter seg og hver bruker ser en advarsel om endret nøkkel ved første bruk. Å sette aliaset holder known-hosts-oppføringer stabile mens forbindelsen fortsatt går til reléet.

Dette aliaset gjelder bare for SSH-baserte fjernlagre. En HTTPS-Git-URL konsulterer det ikke, og den typiske fjern-URL-en må samsvare med transporten du faktisk har etablert.

Det du ikke må gjøre, er å deaktivere vertsnøkkelverifisering for å bli kvitt advarselen. Det fjerner en beskyttelse som videresendingsreparasjonen aldri ba om å røre, og det gjør en kosmetisk irritasjon til en reell eksponering.

Verifiser hvert hopp separat

Test den offentlige lytteren alene, deretter relé-til-backend-forbindelsen fra reléverten, og først da klienten ende til ende. Hver av de tre testene utelukker et forskjellig lag. Hoppes en over, betyr det at de to gjenværende resultatene ikke kan tolkes. Tre observasjoner, tre steder hvor en feil kan bo.

Ta vare på måladressen, porten og de første protokollbyttene sammen med hvert resultat. Den trioen skiller en kantfeil fra et VPN-rutingproblem fra en SSH-autentiseringsfeil, og det er forskjellen mellom en reparasjon og en gjetning.

Til slutt, dokumenter den tilsiktede eksponeringen. Et TCP-relé som fører SSH til en privat backend er en bevisst åpning i den offentlige perimeteren, og det fortjener samme gjennomgang som enhver annen inngående tjeneste.

Relaterte artikler