NGINX oqim relesi orqali SSH — buzmasdan

PROXY sarlavhasi uni kutayotgan qabul qiluvchiga yuborilgan xabar, proksilangan DNS yozuvi esa TCP rele emas. Chekka va yuqori oqimni alohida tuzating.

Relye orqali ommaviy SSH ikkita bog'liq bo'lmagan chegarada muvaffaqiyatsiz bo'ladi va bittasini tuzatish odatda ikkinchisini ochib beradi. Yo chekka oqimni tashish o'rniga HTTP javobini qaytaradi, yo rele backend hech qachon o'qishga rozi bo'lmagan sarlavhani oldiga qo'shadi. Qaysi birini ko'rayotganingizni uchta shart belgilaydi: ommaviy yozuv aslida nimaga ishora qiladi, oqim bloki yuqoriga nima yuboradi va SSH mijozi qaysi nomni tekshiradi. Ularni shu tartibda hal qiling.

Ikki chegara, ikki alomat

Chekkadagi nosozlik SSH banneri bo'lishi kerak joyga HTTP holat sahifasi kelayotgandek ko'rinadi. Ulanish TCP darajasida tugaydi va birinchi baytlar veb-serverga tegishli matn. Bu protokol nomuvofiqligi, yo'qolgan paket emas. Shuningdek, chekka o'sha nom uchun ataylab boshqa narsani taqdim etayotganini aytadi.

Yuqori oqimdagi nosozlik boshqacha ko'rinadi. Ulanish sshd ga yetib boradi, sshd kutgan identifikatsiya almashinuvi bo'lmagan baytlarni o'qiydi va sessiya hech qachon kalit taklif qilmasdan o'ladi yoki muzlab qoladi.

Bu ikkisini chalkashtirish oson, chunki ikkisi ham ulanib, keyin muvaffaqiyatsiz bo'ladigan mijoz yaratadi. Siz olgan birinchi protokol javobi ularni ajratadi, shuning uchun u biletda bo'lishi kerak.

PROXY sarlavhasi — xabar, kalit emas

Oqim modulida proxy_protocol on NGINX ga foydali yukdan oldin yuqori tomonga PROXY protokol sarlavhasini yozishni buyuradi. Bu TCP proksisini yoqmaydi va SSH shifrlashga hech qanday aloqasi yo'q. Bu qabul qiluvchiga qaratilgan eslatma. Qabul qiluvchi uni o'qiy olmasa, u oqim boshida axlatga aylanadi.

Qabul qiluvchi xizmat o'sha sarlavhani ataylab iste'mol qilishi kerak. Oddiy sshd ulanishning birinchi baytlari sifatida SSH identifikatsiya almashinuvini kutadi, shuning uchun kutilmagan muqaddima qo'l berib ko'rishishni buzilgan serverga o'xshab buzadi.

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

Bu parcha VPN orqali yetib boriladigan backend uchun to'liq ishlaydigan rele. Hech qanday PROXY ko'rsatmasi ko'rinmaydi, chunki qabul qiluvchi bu protokolni bilmaydi va bu yo'qlik — qaror, o'tkazib yuborish emas.

Ikki yo'nalishni ham ajrating. listen satrida proxy_protocol o'rnatish NGINX o'z mijozining sarlavhani birinchi yuborishini kutishini bildiradi; uni oddiy SSH mijozi uchun yoqish odamlar odatda hal qilishga urinadigan muammoning aynan teskarisini keltirib chiqaradi.

Ommaviy xost nomi aslida qayerga yetadi

SSH sessiyasidagi HTTP 400 sahifasi chekka haqida dalil. Yo'lda nimadir HTTP gapiradi va backendda kalit yoki hisob ustidagi hech qanday ish buni o'zgartirmaydi. Chekka hal bo'lmaguncha backendni o'zgartirishni to'xtating.

Cloudflare ning oddiy proksilangan yozuvi qo'llab-quvvatlanadigan HTTP va HTTPS trafigini belgilangan portlarda tashiydi. Xost nomi uchun proksini yoqish umumiy TCP rele yaratmaydi va SSH ni 443 portiga ko'chirish uni HTTPS qilmaydi.

Ikki amaliy yo'nalish mavjud. Faqat DNS yozuvi o'z TCP relengizga ishora qilishi mumkin, bu esa ta'sir qilish qarorini sizning qo'lingizda qoldiradi. Yoki SSH tashishni aniq hujjatlashtiruvchi mahsulotdan foydalaning, o'zining manba, mijoz va kirish konfiguratsiyasi bilan.

Nimani tanlasangiz ham, rele backendga VPN yo'li, ruxsat etilgan ulanish va qaytish yo'lini talab qiladi. Yo'l, ommaviy tomon ishlagani uchun ixtiyoriy emas.

SSH shaxsini laqab orqali barqaror saqlang

Foydalanuvchilar odatda o'zlarining mavjud xost nomini yozishni davom ettirishni xohlaydi. SSH konfiguratsiyasidagi laqab buni relda hech narsani o'zgartirmasdan amalga oshira oladi va o'zgarishni u tegishli bo'lgan mijoz tomonida qoldiradi.

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

HostKeyAlias bo'lmasa, OpenSSH xost kalitini ulanadigan nomi ostida qidiradi, shuning uchun yozuv siljiydi va har bir foydalanuvchi birinchi ishlatishda kalit o'zgargani haqidagi ogohlantirishni ko'radi. Laqabni o'rnatish known-hosts yozuvlarini barqaror saqlaydi, ulanish esa hali ham relga boradi.

Bu laqab faqat SSH asosidagi uzoq omborlarga tegishli. HTTPS Git URL unga murojaat qilmaydi va odatiy uzoq URL siz haqiqatan tayyorlagan transportga mos kelishi kerak.

Qilmasligingiz kerak bo'lgan narsa — ogohlantirish yo'qolishi uchun xost kaliti tekshiruvini o'chirish. Bu yo'naltirish ta'miri hech qachon teginishni so'ramagan himoyani olib tashlaydi va ko'rinishdagi noqulaylikni haqiqiy ta'sirga aylantiradi.

Har bir sakrashni alohida tekshiring

Ommaviy tinglovchini yolg'iz sinang, so'ngra rele xostidan rele-backend ulanishini va shundan keyingina mijozni boshidan oxirigacha sinang. O'sha uchta sinovning har biri boshqa qatlamni istisno qiladi. Bittasini o'tkazib yuborish qolgan ikki natijani izohlash mumkin emasligini bildiradi. Uch kuzatuv, nosozlik yashashi mumkin bo'lgan uch joy.

Har bir natija bilan birga manzil, port va birinchi protokol baytlarini saqlang. Bu uchlik chekka xatosini VPN marshrutlash muammosidan va SSH autentifikatsiya nosozligidan ajratadi, va bu ta'mirlash bilan taxmin o'rtasidagi farq.

Nihoyat, rejalashtirilgan ta'sirni hujjatlashtiring. SSH ni shaxsiy backendga tashuvchi TCP rele ommaviy perimetrda ataylab ochilgan teshik va u boshqa har qanday kiruvchi xizmat kabi ko'rib chiqishga loyiq.

O'xshash maqolalar