SSH troch in NGINX-streamrelay sûnder it te brekken

In PROXY-kop is in berjocht foar in ûntfanger dy't it ferwachtet, en in proxyfearre DNS-record is gjin TCP-relay. Reparearje de râne en de boppestream apart.

Iepenbiere SSH troch in relay mislearret op twa net besibbe grinzen, en it reparearjen fan ien iepenbiere meastentiids de oare. Of de râne jout in HTTP-antwurd werom ynstee fan in stream te ferfieren, of de relay set in kop foarop dy't de backend nea tostien hat te lêzen. Trije betingsten bepale hokker jo sjogge: wêr't it iepenbiere record eins nei wiist, wat it streamblok boppestream stjoert en hokker namme de SSH-klient ferifiearret. Wurkje se yn dy folchoarder ôf.

Twa grinzen, twa symptomen

In flater oan 'e râne liket op in HTTP-statusside dy't oankomt wêr't in SSH-banner wêze moat. De ferbining foltôget op TCP-nivo en de earste bytes binne tekst dy't by in webserver heart. Dat is in protokolôfwiking, gjin ferlern pakket. It fertelt jo ek dat de râne foar dy namme bewust wat oars betsjinnet.

In flater oan 'e boppestream liket oars. De ferbining berikt sshd, sshd lêst bytes dy't net de identifikaasje-útwikseling binne dy't it ferwachtet, en de sesje stjert of hinget sûnder ea in kaai oan te bieden.

Dy twa binne maklik te betiizjen, want beide leverje in klient dy't ferbynt en dan mislearret. It earste protokolantwurd dat jo krije is wat se ûnderskiedt, en dêrom heart it yn 'e kaart.

De PROXY-kop is in berjocht, gjin skeakel

Yn de streammodule seit proxy_protocol on tsjin NGINX om foar de lading in PROXY-protokolkop nei de boppestream te skriuwen. It skeakelet gjin TCP-proxy yn, en it hat neat mei SSH-fersifering te meitsjen. It is in notysje rjochte oan 'e ûntfanger. Kin de ûntfanger it net lêze, dan wurdt it jiskefet oan it begjin fan 'e stream.

De ûntfangende tsjinst moat dy kop bewust konsumearje. In normale sshd ferwachtet de SSH-identifikaasje-útwikseling as de earste bytes fan 'e ferbining, dat in ûnferwachte foaropwurd brekt de hânskudding op in wize dy't op in skansearre server liket.

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

Dat fragmint is it gehiel fan in wurkjende relay foar in backend dy't tagonklik is oer it VPN. Der ferskynt gjin PROXY-direktive, om't de ûntfanger it protokol net sprekt, en dat ûntbrekken is in beslút, gjin ferjitten.

Skift ek de beide rjochtingen. proxy_protocol op 'e listen-rigel sette betsjut dat NGINX ferwachtet dat syn eigen klient de kop earst stjoert; it ynskeakelje foar in gewoane SSH-klient produsearret krekt it tsjinoerstelde fan it probleem dat minsken meastentiids besykje op te lossen.

Wat de iepenbiere hostnamme eins berikt

In HTTP 400-side yn in SSH-sesje is bewiis oer de râne. Iets op it paad sprekt HTTP, en gjin hoemannichte kaai- of akkountwurk by de backend sil dat feroarje. Stopje mei it feroarjen fan 'e backend oant de râne klear is.

It gewoane proxyfearre record fan Cloudflare ferfiert syn stipe HTTP- en HTTPS-ferkear op fêststelde poarten. It ynskeakeljen fan 'e proxy foar in hostnamme makket gjin algemiene TCP-relay, en SSH nei poarte 443 ferpleatse makket it gjin HTTPS.

Der besteane twa útfierbere rjochtingen. In record mei allinnich DNS kin nei jo eigen TCP-relay wize, wat it beslút oer bleatstelling yn jo hannen leit. As alternatyf brûk in produkt dat SSH-ferfier eksplisyt dokumintearret, mei syn eigen oarsprong-, klient- en tagongsynstelling.

Hokker jo ek kieze, de relay hat noch altyd in VPN-rûte nei de backend, in tastiene ferbining en in weromwei nedich. De rûte is net opsjoneel, om't de iepenbiere kant wurket.

Hâld de SSH-identiteit stabyl fia in alias

Brûkers wolle meastentiids har besteande hostnamme trochgeane mei typen. In alias yn 'e SSH-konfiguraasje kin dat dwaan sûnder eat oan 'e relay te feroarjen, en it hâldt de feroaring oan 'e kliïntkant, wêr't it heart.

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

Sûnder HostKeyAlias siket OpenSSH de hostkaai ûnder de namme dêr't it mei ferbynt, dat de yngong ferpleatst him en elke brûker sjocht by it earste gebrûk in warskôging oer in feroare kaai. It alias ynstelle hâldt known-hosts-yngongen stabyl wylst de ferbining noch altyd nei de relay giet.

Dit alias jildt allinnich foar op SSH basearre fiere repositories. In HTTPS-Git-URL rieplachtsje it net, en de typyske fiere URL moat oerienkomme mei it ferfier dat jo eins ynrjochte hawwe.

Wat jo net dwaan moatte, is de hostkaaiverifikaasje útskeakelje om de warskôging fuort te krijen. Dat hellet in beskerming fuort dy't de trochstjoerrepresje nea frege hat om oan te reitsjen, en it makket in kosmetyske ergernis ta in echte bleatstelling.

Ferifiearje elke hop apart

Test de iepenbiere listener op himsels, dan de relay-nei-backend-ferbining fan 'e relayhost, en pas dêrnei de klient fan ein oant ein. Elk fan dy trije tests slút in oare laach út. Ien oerslaan betsjut dat de oare twa resultaten net ynterpretearre wurde kinne. Trije waarnimmings, trije plakken dêr't in flater libje kin.

Hâld it bestimmingsadres, de poarte en de earste protokolbytes by elk resultaat. Dat trijetal ûnderskiedt in râneflater fan in VPN-rûteprobleem en fan in SSH-autentikaasjeflater, en it is it ferskil tusken in represje en in gissing.

Dokumintearje úteinlik de bedoelde bleatstelling. In TCP-relay dy't SSH nei in privee backend ferfiert, is in bewuste iepening yn 'e iepenbiere perimeter, en it fertsjinnet deselde beoardieling as elke oare ynkommende tsjinst.

Relatearre artikelen