SSH NGINX-virtareleen läpi sitä rikkomatta

Julkinen SSH releen läpi epäonnistuu kahdella toisiinsa liittymättömällä rajalla, ja toisen korjaaminen paljastaa yleensä toisen. Reuna joko palauttaa HTTP-vastauksen virran kuljettamisen sijaan tai rele lisää eteen otsakkeen, jota tausta ei koskaan suostunut lukemaan. Kolme ehtoa ratkaisee, kumpaa katsot: mihin julkinen tietue todella osoittaa, mitä virtalohko lähettää ylävirtaan ja mitä nimeä SSH-asiakas vahvistaa. Käsittele ne tässä järjestyksessä.

Kaksi rajaa, kaksi oiretta

Reunan vika näyttää siltä kuin HTTP-tilasivu saapuisi sinne, missä SSH-bannerin pitäisi olla. Yhteys täydentyy TCP-tasolla ja ensimmäiset tavut ovat tekstiä, joka kuuluu verkkopalvelimelle. Se on protokollan epäjohdonmukaisuus, ei kadonnut paketti. Se kertoo myös, että reuna palvelee tarkoituksella jotain muuta tuolle nimelle.

Ylävirran vika näyttää erilaiselta. Yhteys saavuttaa sshd:n, sshd lukee tavuja, jotka eivät ole odotettu tunnistautumisvaihto, ja istunto kuolee tai jää jumiin tarjoamatta koskaan avainta.

Nämä kaksi on helppo sekoittaa, koska molemmat tuottavat asiakkaan, joka yhdistää ja sitten epäonnistuu. Ensimmäinen saamasi protokollavastaus erottaa ne, ja siksi se kuuluu tikettiin.

PROXY-otsake on viesti, ei kytkin

Virtamoduulissa proxy_protocol on käskee NGINXin kirjoittaa PROXY-protokollaotsakkeen kohti ylävirtaa ennen hyötykuormaa. Se ei ota TCP-välitystä käyttöön, eikä sillä ole mitään tekemistä SSH-salauksen kanssa. Se on vastaanottajalle osoitettu muistiinpano. Jos vastaanottaja ei voi lukea sitä, siitä tulee roskaa virran alussa.

Vastaanottavan palvelun on kulutettava tämä otsake tarkoituksella. Normaali sshd odottaa SSH-tunnistautumisvaihtoa yhteyden ensimmäisinä tavuina, joten odottamaton johdanto rikkoo kättelyn tavalla, joka näyttää vioittuneelta palvelimelta.

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

Tuo katkelma on kokonaisuudessaan toimiva rele VPN:n kautta tavoitettavalle taustalle. PROXY-direktiiviä ei näy, koska vastaanottaja ei puhu protokollaa, ja tuo puuttuminen on päätös eikä laiminlyönti.

Erottele myös molemmat suunnat. proxy_protocol-asetus listen-rivillä tarkoittaa, että NGINX odottaa oman asiakkaansa lähettävän otsakkeen ensin; sen ottaminen käyttöön tavalliselle SSH-asiakkaalle tuottaa täsmälleen päinvastaisen ongelman kuin mitä yleensä yritetään ratkaista.

Mihin julkinen isäntänimi todella päätyy

HTTP 400 -sivu SSH-istunnossa on todiste reunasta. Jokin polussa puhuu HTTP:tä, eikä mikään avain- tai tilityö taustassa muuta sitä. Lopeta taustan muuttaminen, kunnes reuna on ratkaistu.

Cloudflaren tavallinen välityspalveltu tietue kuljettaa tuetun HTTP- ja HTTPS-liikenteensä määritetyillä porteilla. Välityksen kytkeminen päälle isäntänimelle ei luo yleistä TCP-relettä, eikä SSH:n siirtäminen porttiin 443 tee siitä HTTPS:ää.

On kaksi toteuttamiskelpoista suuntaa. Vain DNS -tietue voi osoittaa omaan TCP-releeseesi, mikä jättää altistumispäätöksen käsiisi. Vaihtoehtoisesti käytä tuotetta, joka dokumentoi SSH-kuljetuksen nimenomaisesti, omalla alkuperä-, asiakas- ja käyttöoikeusmäärityksellään.

Minkä tahansa valitset, rele tarvitsee edelleen VPN-reitin taustaan, sallitun yhteyden ja paluupolun. Reitti ei ole valinnainen siksi, että julkinen puoli toimii.

Pidä SSH-identiteetti vakaana aliaksen avulla

Käyttäjät haluavat yleensä jatkaa nykyisen isäntänimensä kirjoittamista. SSH-kokoonpanon alias voi tehdä sen muuttamatta releestä mitään, ja se pitää muutoksen asiakkaan puolella, minne se kuuluu.

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

Ilman HostKeyAlias-asetusta OpenSSH etsii isäntäavaimen sen nimen alta, johon se yhdistää, joten merkintä siirtyy ja jokainen käyttäjä näkee ensimmäisellä käytöllä varoituksen vaihtuneesta avaimesta. Aliaksen asettaminen pitää known-hosts-merkinnät vakaina, kun yhteys menee edelleen releeseen.

Tämä alias koskee vain SSH-pohjaisia etävarastoja. HTTPS-muotoinen Git-URL ei kysy sitä, ja tyypillisen etä-URL:n on vastattava transporttia, jonka todella valmistelit.

Sitä sinun ei pidä tehdä, että poistat isäntäavaimen tarkistuksen, jotta varoitus katoaisi. Se poistaa suojauksen, jota edelleenohjauksen korjaus ei koskaan pyytänyt koskemaan, ja muuttaa kosmeettisen harmin todelliseksi altistumiseksi.

Vahvista jokainen hyppy erikseen

Testaa julkista kuuntelijaa yksinään, sitten releen ja taustan välistä yhteyttä releen isännältä ja vasta sitten asiakasta päästä päähän. Jokainen näistä kolmesta testistä sulkee pois eri kerroksen. Yhden väliin jättäminen tarkoittaa, että kahta jäljellä olevaa tulosta ei voi tulkita. Kolme havaintoa, kolme paikkaa, joissa vika voi elää.

Pidä kohdeosoite, portti ja ensimmäiset protokollatavut jokaisen tuloksen mukana. Tämä kolmikko erottaa reunavian VPN-reititysongelmasta ja SSH-todennuksen epäonnistumisesta, ja se on ero korjauksen ja arvauksen välillä.

Dokumentoi lopuksi aiottu altistuminen. TCP-rele, joka kuljettaa SSH:n yksityiseen taustaan, on tarkoituksellinen avaus julkisessa kehässä, ja se ansaitsee saman tarkastelun kuin mikä tahansa muu saapuva palvelu.