SSH د NGINX د جریان ریلې له لارې پرته له ماتېدو

د رېلې له لارې عامه SSH په دوو نااړوندو پولو کې ناکامېږي، او د یوې اصلاح معمولاً بلې ته ښکاره کوي۔ یا څنډه د جریان د لېږد پرځای HTTP ځواب بېرته ورکوي، یا رېله مخکې هغه سرلیک ور زیاتوي چې شاته برخه هیڅکله د لوستلو موافقه نه ده کړې۔ درې شرطونه ټاکي چې تاسو کوم یو وینئ: عامه ریکارډ واقعاً څه ته اشاره کوي، د جریان بلاک پورتنۍ خوا ته څه لېږي، او SSH کلاینټ کوم نوم تصدیقوي۔ په همدې ترتیب سره ورسره کار وکړئ۔

دوه پولې، دوه نښې

د څنډې ناکامي داسې ښکاري لکه چې د SSH بینر په ځای کې د HTTP حالت پاڼه راروانه ده۔ اړیکه د 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 لارښود نه ښکاري ځکه ترلاسه کوونکی هغه پروتوکول نه بولي، او هغه نشتوالی پریښودل نه، یو پرېکړه ده۔

دواړه لوري هم جلا کړئ۔ په listen کرښه کې proxy_protocol ټاکل یعنې 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 شخصي شاته برخې ته وړي، په عامه چاپېریال کې قصداً پرانیستل شوې دروازه ده، او د هر بل راتلونکي خدمت په څیر د هماغې بیاکتنې وړ ده۔