د OpenSSH 8.5 خوشې کول

د پنځو میاشتو پراختیا وروسته، د OpenSSH 8.5 خوشې کول، د SSH 2.0 او SFTP پروتوکولونو باندې کار کولو لپاره د پیرودونکي او سرور خلاص تطبیق، وړاندې کیږي.

د OpenSSH پرمخ وړونکو موږ ته د SHA-1 هشونو په کارولو سره د الګوریتمونو راتلونکي تخریب یادونه وکړه چې د ورکړل شوي مخفف سره د ټکر بریدونو ډیر موثریت له امله (د ټکر غوره کولو لګښت شاوخوا $ 50 زره اټکل شوی). په راتلونکو خپرونو کې، دوی پالن لري چې د ډیفالټ لخوا د "ssh-rsa" عامه کلیدي ډیجیټل لاسلیک الګوریتم کارولو وړتیا غیر فعال کړي، کوم چې د SSH پروتوکول لپاره په اصلي RFC کې یادونه شوې او په عمل کې پراخه پاتې کیږي.

ستاسو په سیسټمونو کې د ssh-rsa کارولو ازموینې لپاره، تاسو کولی شئ د "-oHostKeyAlgorithms=-ssh-rsa" اختیار سره د ssh له لارې د نښلولو هڅه وکړئ. په ورته وخت کې، د ډیفالټ لخوا د "ssh-rsa" ډیجیټل لاسلیکونو غیر فعال کول د RSA کلیدونو کارولو بشپړ پریښودل معنی نلري، ځکه چې د SHA-1 سربیره، د SSH پروتوکول د نورو هش حساب کولو الګوریتمونو کارولو ته اجازه ورکوي. په ځانګړې توګه، د "ssh-rsa" سربیره، دا به د "rsa-sha2-256" (RSA/SHA256) او "rsa-sha2-512" (RSA/SHA512) بنډلونو کارول ممکن پاتې شي.

نوي الګوریتمونو ته د لیږد اسانه کولو لپاره ، OpenSSH 8.5 د UpdateHostKeys ترتیب د ډیفالټ لخوا فعال شوی ، کوم چې پیرودونکو ته اجازه ورکوي په اتوماتيک ډول ډیر معتبر الګوریتمونو ته لاړ شي. د دې ترتیب په کارولو سره، د ځانګړي پروتوکول توسیع فعال شوی "[ایمیل خوندي شوی]"، سرور ته اجازه ورکوي، د تصدیق کولو وروسته، پیرودونکي ته د ټولو موجود کوربه کیلي په اړه خبر کړي. پیرودونکی کولی شي دا کیلي په خپل ~/.ssh/known_hosts فایل کې منعکس کړي، کوم چې د کوربه کیلي تازه کولو ته اجازه ورکوي او په سرور کې د کیلي بدلول اسانه کوي.

د UpdateHostKeys کارول د څو احتیاطونو لخوا محدود دي چې ممکن په راتلونکي کې لرې شي: کیلي باید د UserKnownHostsFile کې حواله شي او په GlobalKnownHostsFile کې نه کارول کیږي؛ کیلي باید یوازې د یو نوم لاندې شتون ولري؛ د کوربه کلیدي سند باید ونه کارول شي؛ په پیژندل شوي_hosts کې د کوربه نوم لخوا ماسکونه باید ونه کارول شي؛ د VerifyHostKeyDNS ترتیب باید غیر فعال وي؛ د UserKnownHostsFile پیرامیټر باید فعال وي.

د مهاجرت لپاره وړاندیز شوي الګوریتمونه شامل دي rsa-sha2-256/512 د RFC8332 RSA SHA-2 پر بنسټ (د OpenSSH 7.2 راهیسې ملاتړ شوی او په ډیفالټ کارول کیږي)، ssh-ed25519 (د OpenSSH 6.5 راهیسې ملاتړ شوی) او ecdsa-sha2-nistp256/384/521 په RFC5656 ECDSA کې (د OpenSSH 5.7 راهیسې ملاتړ شوی).

نور بدلونونه:

  • امنیتي بدلونونه:
    • د پخوا څخه خلاص شوي حافظې ساحې (ډبل فری) د بیا خلاصولو له امله رامینځته شوی زیان په ssh-agent کې ټاکل شوی. دا مسله د OpenSSH 8.2 له خپریدو راهیسې شتون لري او په احتمالي توګه کارول کیدی شي که چیرې برید کونکی په محلي سیسټم کې د ssh-اجنټ ساکټ ته لاسرسی ولري. هغه څه چې استخراج ډیر ستونزمن کوي ​​دا دی چې یوازې ریښه او اصلي کارونکي ساکټ ته لاسرسی لري. د برید ترټولو احتمالي سناریو دا ده چې اجنټ هغه حساب ته لیږل کیږي چې د برید کونکي لخوا کنټرول کیږي ، یا یو کوربه ته چیرې چې برید کونکی ریښی لاسرسی لري.
    • sshd د PAM فرعي سیسټم ته د کارونکي نوم سره د خورا لوی پیرامیټرو تیرولو پروړاندې محافظت اضافه کړی ، کوم چې تاسو ته اجازه درکوي د PAM (پلګ ایبل تصدیق کولو ماډل) سیسټم ماډلونو کې زیان منونکي بلاک کړئ. د مثال په توګه، بدلون sshd د ویکتور په توګه د کارولو مخه نیسي ترڅو په سولارس (CVE-2020-14871) کې د وروستي کشف شوي ریښې زیان څخه ګټه پورته کړي.
  • په احتمالي توګه د مطابقت بدلونونه ماتول:
    • В ssh и sshd переработан экспериментальный метод обмена ключами, стойкий к подбору на квантовом компьютере. Квантовые компьютеры кардинально быстрее решают задачу разложения натурального числа на простые множители, которая лежит в основе современных асимметричных алгоритмов шифрования и эффективно не решаема на классических процессорах. Используемый метод основан на алгоритме NTRU Prime, разработанном для постквантумных криптосистем, и методе обмена ключами на базе эллиптических кривых X25519. Вместо [ایمیل خوندي شوی] метод теперь идентифицируется как [ایمیل خوندي شوی] (sntrup4591761 الګوریتم د sntrup761 لخوا بدل شوی دی).
    • په ssh او sshd کې، هغه ترتیب چې د ملاتړ شوي ډیجیټل لاسلیک الګوریتم اعلان شوی بدل شوی. ED25519 اوس د ECDSA پرځای لومړی وړاندیز شوی.
    • په ssh او sshd کې، د متقابل غونډو لپاره د خدماتو پیرامیټونو د TOS/DSCP کیفیت تنظیم کول اوس د TCP اتصال رامینځته کولو دمخه ترسره کیږي.
    • د سیفر ملاتړ په ssh او sshd کې بند شوی دی [ایمیل خوندي شوی]، کوم چې د aes256-cbc سره ورته دی او د RFC-4253 تصویب کیدو دمخه کارول شوی و.
    • د ډیفالټ په واسطه، د CheckHostIP پیرامیټر غیر فعال دی، چې ګټه یې د پام وړ نه ده، مګر د دې کارول د بار بار بیلنسونو شاته د کوربه لپاره کلیدي گردش پیچلي کوي.
  • PerSourceMaxStartups او PerSourceNetBlockSize ترتیبات په sshd کې اضافه شوي ترڅو د پیرودونکي پتې پراساس د هینډلر لانچ کولو شدت محدود کړي. دا پیرامیټونه تاسو ته اجازه درکوي چې د عمومي MaxStartups ترتیب په پرتله د پروسې په پیل کې محدودیت ډیر ښه کنټرول کړئ.
  • یو نوی LogVerbose ترتیب په ssh او sshd کې اضافه شوی، کوم چې تاسو ته اجازه درکوي چې په لاګ کې ډوب شوي د ډیبګ کولو معلوماتو کچه په زور سره لوړه کړئ، د ټیمپلیټونو، فنکشنونو او فایلونو لخوا د فلټر کولو وړتیا سره.
  • په ssh کې، کله چې د نوي کوربه کیلي ومنل شي، ټول کوربه نومونه او د کیلي سره تړلي IP پتې ښودل کیږي.
  • ssh UserKnownHostsFile=None اختیار ته اجازه ورکوي چې د پیژندل شوي_hosts فایل کارول غیر فعال کړي کله چې د کوربه کیلي پیژني.
  • د KnownHostsCommand ترتیب د ssh لپاره ssh_config کې اضافه شوی، تاسو ته اجازه درکوي د ټاکل شوي کمانډ له محصول څخه د معلوم_هوسټ ډیټا ترلاسه کړئ.
  • د ssh لپاره ssh_config ته د PermitRemoteOpen اختیار اضافه شوی ترڅو تاسو ته اجازه درکړي چې منزل محدود کړئ کله چې د SOCKS سره د RemoteForward اختیار کاروئ.
  • د FIDO کلیدونو لپاره په ssh کې، د غلط PIN له امله د ډیجیټل لاسلیک عملیاتو ناکامۍ په صورت کې د PIN تکرار غوښتنه چمتو کیږي او کارونکي د PIN لپاره نه هڅول کیږي (د مثال په توګه، کله چې سم بایومیټریک ډاټا نشي ترلاسه کولی او وسیله بیرته د لاسي PIN ننوتلو ته راښکته شوه).
  • sshd په لینکس کې د seccomp-bpf-based پروسې جلا کولو میکانیزم ته د اضافي سیسټم تلیفونونو لپاره ملاتړ اضافه کوي.
  • د شراکت/ssh-copy-id استعمال تازه شوی دی.

سرچینه: opennet.ru

Add a comment