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 до приватен бекенд е намерно отворена дупка во јавниот периметар, и заслужува ист преглед како секоја друга влезна услуга.

Поврзани статии