SSH кроз NGINX стрим релеј без ломљења

PROXY заглавље је порука за примаоца који га очекује, а проксирани DNS запис није TCP релеј. Поправите ивицу и узводну страну одвојено.

Јавни SSH кроз релеј пада на две неповезане границе, и поправка једне обично открива другу. Или ивица враћа одговор HTTP уместо да преноси ток, или релеј додаје напред заглавље које бекенд никада није пристао да чита. Три услова одређују шта видите: на шта јавни запис заправо указује, шта блок тока шаље према горе и које име SSH клијент проверава. Обрадите их тим редом.

Две границе, два симптома

Дефект на ивици изгледа као страница стања HTTP која стиже тамо где би требало да буде SSH банер. Веза се успоставља на TCP нивоу и први бајтови су текст који припада веб серверу. То је несагласност протокола, а не изгубљен пакет. Такође вам каже да ивица намерно сервира нешто друго за то име.

Дефект на узводној страни изгледа другачије. Веза стиже до sshd, sshd чита бајтове који нису очекивана размена идентификације, и сесија умире или виси без икада понуђеног кључа.

Ова два је лако помешати јер оба дају клијента који се повеже и затим падне. Први одговор протокола који примите је оно што их разликује, зато он и припада тикету.

PROXY заглавље је порука, а не прекидач

У модулу тока proxy_protocol on налаже NGINX-у да пре корисног терета упише заглавље протокола PROXY у смеру узводне стране. То не укључује TCP проксирање и нема никакве везе са SSH шифровањем. То је белешка упућена примаоцу. Ако прималац не може да је прочита, она постаје отпад на почетку тока.

Услуга која прима мора намерно да конзумира то заглавље. Нормалан sshd очекује размену идентификације SSH као прве бајтове везе, па неочекивани увод квари руковање на начин који изгледа као оштећен сервер.

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

Тај фрагмент је целина исправног релеја за бекенд доступан преко VPN-а. Не појављује се никаква PROXY директива јер прималац не говори тај протокол, и то одсуство је одлука, а не пропуст.

Одвојите и оба смера. Постављање proxy_protocol на линију listen значи да NGINX очекује да његов сопствени клијент први пошаље заглавље; укључивање за обичан SSH клијент даје тачно супротно од проблема који људи обично покушавају да реше.

Шта јавно име домаћина заправо достиже

Страница HTTP 400 у SSH сесији је доказ о ивици. Нешто на путу говори HTTP, и никакав рад са кључем или налогом на бекенду то неће променити. Престаните да мењате бекенд док ивица не буде решена.

Обичан проксиран запис Cloudflare преноси свој подржани HTTP и HTTPS саобраћај на одређеним портовима. Укључивање проксија за име домаћина не ствара општи TCP релеј, а премештање SSH-а на порт 443 не чини га HTTPS-ом.

Постоје два изводљива смера. Запис само са DNS-ом може да указује на ваш сопствени TCP релеј, што одлуку о изложености оставља у вашим рукама. Алтернативно, користите производ који експлицитно документује пренос SSH-а, са сопственом конфигурацијом порекла, клијента и приступа.

Шта год да изаберете, релеју је и даље потребна VPN рута до бекенда, дозвољена веза и повратни пут. Рута није опциона јер јавна страна ради.

Одржите SSH идентитет стабилним преко псеудонима

Корисници обично желе да наставе да куцају своје постојеће име домаћина. Псеудоним у SSH конфигурацији може то да уради без икакве промене на релеју, и задржава промену на страни клијента где јој је место.

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

Без HostKeyAlias, OpenSSH тражи кључ домаћина под именом са којим се повезује, па се запис помера и сваки корисник при првој употреби види упозорење о промењеном кључу. Постављање псеудонима одржава записе у known-hosts стабилним док веза и даље иде ка релеју.

Овај псеудоним важи само за удаљена складишта заснована на SSH-у. HTTPS Git URL га не консултује, и типичан удаљени URL мора да одговара транспорту који сте стварно припремили.

Оно што не треба да урадите је да искључите проверу кључа домаћина да би упозорење нестало. То уклања заштиту коју поправка прослеђивања никада није тражила да се дотакне, и претвара козметичку непријатност у стварну изложеност.

Проверите сваки скок одвојено

Тестирајте јавни слушалац сам, затим везу од релеја до бекенда са домаћина релеја, и тек онда клијента од краја до краја. Сваки од та три теста искључује други слој. Прескакање једног значи да се преостала два резултата не могу протумачити. Три запажања, три места где дефект може да живи.

Сачувајте адресу одредишта, порт и прве бајтове протокола уз сваки резултат. Та тројка разликује грешку ивице од проблема са VPN рутирањем и од неуспеха SSH аутентикације, и то је разлика између поправке и претпоставке.

На крају, документујте предвиђену изложеност. TCP релеј који преноси SSH до приватног бекенда је намерно отворен отвор у јавном периметру, и заслужује исти преглед као и свака друга улазна услуга.

Повезани чланци