SSH NGINX-ի հոսքային ռելեով՝ առանց այն կոտրելու

Հանրային 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 հաճախորդի համար միացնելը ստեղծում է ճիշտ հակառակը այն խնդրի, որը մարդիկ սովորաբար փորձում են լուծել։

Ինչի է իրականում հասնում հանրային հոսթի անունը

SSH նստաշրջանում HTTP 400 էջը ապացույց է եզրի մասին։ Ուղու վրա ինչ-որ բան խոսում է 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 է տանում դեպի մասնավոր հետին մաս, դիտավորյալ բացվածք է հանրային պարագծում, և այն արժանի է նույն վերանայմանը, ինչ ցանկացած այլ ներգնա ծառայություն։