NGINX axın relesi ilə SSH-ı pozmadan keçirmək

Reledən keçən ictimai SSH bir-biri ilə əlaqəsiz iki sərhəddə uğursuz olur və birini düzəltmək adətən digərini üzə çıxarır. Kənar ya axını daşımaq əvəzinə HTTP cavabı qaytarır, ya da rele arxa tərəfin oxumağa razılaşmadığı başlığı qabağa əlavə edir. Hansına baxdığınızı üç şərt müəyyən edir: ictimai qeydin həqiqətən nəyə işarə etdiyi, axın blokunun yuxarı axına nə göndərdiyi və SSH müştərisinin hansı adı yoxladığı. Bunları bu ardıcıllıqla işləyin.

İki sərhəd, iki simptom

Kənardakı nasazlıq SSH bannerinin gəlməli olduğu yerə HTTP status səhifəsinin gəlməsi kimi görünür. Bağlantı TCP səviyyəsində tamamlanır və ilk baytlar veb-serverə aid mətndir. Bu, protokol uyğunsuzluğudur, itirilmiş paket deyil. Həm də sizə deyir ki, kənar həmin ad üçün bilərəkdən başqa bir şey təqdim edir.

Yuxarı axındakı nasazlıq başqa cür görünür. Bağlantı sshd-yə çatır, sshd gözlədiyi identifikasiya mübadiləsi olmayan baytları oxuyur və sessiya heç vaxt açar təqdim etmədən ölür və ya asılır.

Bu ikisini qarışdırmaq asandır, çünki hər ikisi qoşulan və sonra uğursuz olan müştəri yaradır. Onları fərqləndirən ilk protokol cavabıdır, buna görə də o, bilete daxil edilməlidir.

PROXY başlığı mesajdır, keçid deyil

axın modulunda proxy_protocol on NGINX-ə yükdən əvvəl yuxarı axına doğru PROXY protokol başlığı yazmağı tapşırır. Bu, TCP proksiləməsini işə salmır və SSH şifrləməsi ilə heç bir əlaqəsi yoxdur. Bu, qəbulediciyə ünvanlanmış qeyddir. Qəbuledici onu oxuya bilmirsə, axının başlanğıcında qalığa çevrilir.

Qəbul edən xidmət həmin başlığı bilərəkdən istehlak etməlidir. Adi sshd bağlantıdakı ilk baytlar kimi SSH identifikasiya mübadiləsini gözləyir, buna görə gözlənilməz giriş hissəsi əl sıxmanı xarab server kimi görünəcək şəkildə pozur.

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

Bu fraqment VPN vasitəsilə əlçatan arxa tərəf üçün işlək relenin tamamıdır. PROXY direktivi görünmür, çünki qəbuledici protokolu danışmır və bu yoxluq buraxma deyil, qərardır.

İki istiqaməti də ayırın. proxy_protocol sözünü listen sətrində qurmaq NGINX-in öz müştərisinin başlığı əvvəlcə göndərməsini gözlədiyi anlamına gəlir; onu adi SSH müştərisi üçün aktivləşdirmək isə insanların adətən həll etməyə çalışdığı problemin tam əksini yaradır.

İctimai host adı həqiqətən nəyə çatır

SSH sessiyasında HTTP 400 səhifəsi kənar barədə sübutdur. Yolda nəsə HTTP danışır və arxa tərəfdə açar və ya hesab üzərində hansı iş görsəniz də bunu dəyişməyəcək. Kənar həll olunana qədər arxa tərəfi dəyişməyi dayandırın.

Cloudflare-in adi proksilənmiş qeydi dəstəklənən HTTP və HTTPS trafikini müəyyən edilmiş portlarda daşıyır. Host adı üçün proksini açmaq ümumi TCP relesi yaratmır və SSH-ı 443 portuna köçürmək onu HTTPS etmir.

İki işlək istiqamət var. Yalnız DNS qeydi öz TCP relenizə işarə edə bilər, bu da məruzqalma qərarını sizin əlinizə verir. Alternativ olaraq, SSH daşınmasını açıq şəkildə sənədləşdirən, öz mənbəyi, müştərisi və giriş konfiqurasiyası olan məhsuldan istifadə edin.

Hansını seçsəniz də, rele yenə də arxa tərəfə VPN marşrutu, icazə verilmiş bağlantı və geri yol tələb edir. Marşrut opsional deyil, çünki ictimai tərəf işləyir.

SSH kimliyini ləqəb vasitəsilə sabit saxlayın

İstifadəçilər adətən mövcud host adını yazmağa davam etmək istəyirlər. SSH konfiqurasiya ləqəbi bunu reledə heç nə dəyişmədən edə bilər və dəyişikliyi layiq olduğu müştəri tərəfində saxlayır.

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

HostKeyAlias olmadan OpenSSH host açarını qoşulduğu ad altında axtarır, buna görə giriş yerini dəyişir və hər istifadəçi ilk istifadədə dəyişmiş açar xəbərdarlığı görür. Ləqəbi qurmaq known-hosts girişlərini sabit saxlayır, bağlantı isə yenə reledən keçir.

Bu ləqəb yalnız SSH əsaslı uzaq qaynaqlara aiddir. HTTPS Git URL-i ona müraciət etmir və tipik uzaq URL faktiki təmin etdiyiniz nəqliyyata uyğun olmalıdır.

Etməməli olduğunuz şey xəbərdarlığı yox etmək üçün host açarı yoxlamasını söndürməkdir. Bu, yönləndirmə təmirinin toxunmağı xahiş etmədiyi bir müdafiəni aradan qaldırır və kosmetik narahatlığı real məruzqalmaya çevirir.

Hər atlamanı ayrıca yoxlayın

İctimai dinləyicini təkbaşına, sonra rele hostundan rele-arxa tərəf bağlantısını, yalnız bundan sonra müştərini başdan-başa sınaqdan keçirin. Bu üç testin hər biri fərqli bir təbəqəni istisna edir. Birini atlamaq qalan iki nəticənin şərh edilə bilməməsi deməkdir. Üç müşahidə, nasazlığın yaşaya biləcəyi üç yer.

Hər nəticə ilə birlikdə təyinat ünvanını, portu və ilk protokol baytlarını saxlayın. Bu üçlük kənar xətasını VPN marşrut problemi və SSH autentifikasiya nasazlığından ayırır və bu, düzəlişlə təxmin arasındakı fərqdir.

Nəhayət, nəzərdə tutulan məruzqalmanı sənədləşdirin. SSH-ı şəxsi arxa tərəfə daşıyan TCP relesi ictimai perimetrdə qəsdən açılmış dəlikdir və hər hansı digər gələn xidmətlə eyni baxışa layiqdir.