SSH deur 'n NGINX-stroomaflosser sonder om dit te breek

'n PROXY-opskrif is 'n boodskap vir 'n ontvanger wat dit verwag, en 'n geproksieerde DNS-rekord is nie 'n TCP-aflosser nie. Maak die rand en die opstroom afsonderlik reg.

Openbare SSH deur 'n aflosser misluk by twee onverwante grense, en om een reg te maak, openbaar gewoonlik die ander. Die rand gee óf 'n HTTP-antwoord terug in plaas van om 'n stroom te dra, óf die aflosser sit 'n opskrif vooraan wat die agterkant nooit ingestem het om te lees nie. Drie toestande bepaal na watter een jy kyk: waarna die openbare rekord werklik wys, wat die stroomblok opstroom stuur, en watter naam die SSH-kliënt verifieer. Werk hulle in daardie volgorde.

Twee grense, twee simptome

’n Fout by die rand lyk soos ’n HTTP-statusbladsy wat aankom waar ’n SSH-banier moet wees. Die verbinding voltrek op TCP-vlak en die eerste grepe is teks wat aan ’n webbediener behoort. Dit is ’n protokolwanpassing, nie ’n verlore pakkie nie. Dit sê ook vir jou die rand bedien doelbewus iets anders vir daardie naam.

’n Fout by die opstroom lyk anders. Die verbinding bereik sshd, sshd lees grepe wat nie die identifikasie-uitruiling is wat dit verwag nie, en die sessie sterf of hang sonder om ooit ’n sleutel aan te bied.

Dié twee is maklik om te verwar omdat albei ’n kliënt lewer wat koppel en dan misluk. Die eerste protokolantwoord wat jy ontvang, is wat hulle onderskei, en daarom hoort dit in die kaartjie.

Die PROXY-opskrif is ’n boodskap, nie ’n skakelaar nie

In die stroommodule sê proxy_protocol on vir NGINX om ’n PROXY-protokolopskrif na die opstroom te skryf voor die vrag. Dit aktiveer nie TCP-proksering nie, en dit het niks met SSH-enkripsie te doen nie. Dit is ’n nota gerig aan die ontvanger. As die ontvanger dit nie kan lees nie, word dit puin aan die begin van die stroom.

Die ontvangende diens moet daardie opskrif doelbewus verteer. ’n Normale sshd verwag die SSH-identifikasie-uitruiling as die eerste grepe op die verbinding, so ’n onverwagte voorwoord breek die handdruk op ’n manier wat soos ’n korrupte bediener lyk.

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

Daardie fragment is die geheel van ’n werkende aflosser vir ’n agterkant wat oor die VPN bereikbaar is. Geen PROXY-direktief verskyn nie omdat die ontvanger nie die protokol praat nie, en daardie afwesigheid is ’n besluit eerder as ’n weglating.

Skei ook die twee rigtings. Om proxy_protocol op die listen-lyn te stel, beteken NGINX verwag dat sy eie kliënt die opskrif eerste stuur; om dit vir ’n gewone SSH-kliënt te aktiveer, lewer presies die omgekeerde van die probleem wat mense gewoonlik probeer oplos.

Wat die openbare gasheernaam werklik bereik

’n HTTP 400-bladsy in ’n SSH-sessie is bewyse oor die rand. Iets in die pad praat HTTP, en geen mate van sleutel- of rekeningwerk by die agterkant sal dit verander nie. Hou op om die agterkant te verander totdat die rand opgelos is.

Cloudflare se gewone geproksieerde rekord dra sy ondersteunde HTTP- en HTTPS-verkeer op bepaalde poorte. Om die proksie vir ’n gasheernaam aan te skakel, skep nie ’n algemene TCP-aflosser nie, en om SSH na poort 443 te skuif, maak dit nie HTTPS nie.

Twee werkbare rigtings bestaan. ’n Slegs-DNS-rekord kan na jou eie TCP-aflosser wys, wat die blootstellingsbesluit in jou hande plaas. Alternatiewelik gebruik ’n produk wat SSH-vervoer uitdruklik dokumenteer, met sy eie oorsprong-, kliënt- en toegangskonfigurasie.

Watter een jy ook kies, die aflosser het steeds ’n VPN-roete na die agterkant, ’n toegelate verbinding en ’n terugpad nodig. Die roete is nie opsioneel omdat die openbare kant werk nie.

Hou die SSH-identiteit stabiel deur ’n alias

Gebruikers wil gewoonlik aanhou om hul bestaande gasheernaam te tik. ’n SSH-konfigurasie-alias kan dit doen sonder om enigiets aan die aflosser te verander, en dit hou die verandering aan die kliëntkant waar dit hoort.

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

Sonder HostKeyAlias soek OpenSSH die gasheersleutel onder die naam waarmee dit koppel, so die inskrywing skuif en elke gebruiker sien ’n veranderde-sleutel-waarskuwing met die eerste gebruik. Om die alias te stel, hou known-hosts-inskrywings stabiel terwyl die verbinding steeds na die aflosser gaan.

Hierdie alias geld slegs vir SSH-gebaseerde afstande. ’n HTTPS-Git-URL raadpleeg dit nie, en die tipiese afstands-URL moet ooreenstem met die vervoer wat jy werklik voorsien het.

Wat jy nie moet doen nie, is om gasheersleutelverifikasie te deaktiveer om die waarskuwing weg te laat gaan nie. Dit verwyder ’n beskerming wat die deurvoerherstel nooit gevra het om aan te raak nie, en dit verander ’n kosmetiese irritasie in ’n werklike blootstelling.

Verifieer elke sprong afsonderlik

Toets die openbare luisteraar op sy eie, dan die aflosser-tot-agterkant-verbinding vanaf die aflosser-gasheer, en eers dan die kliënt van punt tot punt. Elkeen van daardie drie toetse sluit ’n ander laag uit. Om een oor te slaan, beteken die oorblywende twee resultate kan nie vertolk word nie. Drie waarnemings, drie plekke waar ’n fout kan leef.

Hou die bestemmingsadres, die poort en die eerste protokolgrepe by elke resultaat. Daardie drietal onderskei ’n randfout van ’n VPN-roeteprobleem van ’n SSH-verifikasiefout, en dit is die verskil tussen ’n regstelling en ’n raaiskoot.

Dokumenteer uiteindelik die beoogde blootstelling. ’n TCP-aflosser wat SSH na ’n private agterkant dra, is ’n doelbewuste opening in die openbare omtrek, en dit verdien dieselfde hersiening as enige ander inkomende diens.

Verwante artikels