پانچ ماہ کی ترقی کے بعد، OpenSSH 8.5 کا اجراء، SSH 2.0 اور SFTP پروٹوکول پر کام کرنے کے لیے کلائنٹ اور سرور کا کھلا نفاذ، پیش کیا گیا ہے۔
OpenSSH ڈویلپرز نے ہمیں SHA-1 ہیشز کا استعمال کرتے ہوئے الگورتھم کی آئندہ ڈیکمیشننگ کی یاد دلائی جس کی وجہ ایک دیے گئے سابقے کے ساتھ تصادم کے حملوں کی کارکردگی میں اضافہ ہوا ہے (تصادم کے انتخاب کی لاگت کا تخمینہ تقریباً $50 ہزار ہے)۔ آنے والی ریلیز میں سے ایک میں، وہ "ssh-rsa" عوامی کلید ڈیجیٹل سگنیچر الگورتھم کو استعمال کرنے کی صلاحیت کو بطور ڈیفالٹ غیر فعال کرنے کا ارادہ رکھتے ہیں، جس کا تذکرہ SSH پروٹوکول کے لیے اصل RFC میں کیا گیا ہے اور عملی طور پر وسیع ہے۔
اپنے سسٹمز پر ssh-rsa کے استعمال کو جانچنے کے لیے، آپ ssh کے ذریعے "-oHostKeyAlgorithms=-ssh-rsa" اختیار کے ساتھ جڑنے کی کوشش کر سکتے ہیں۔ ایک ہی وقت میں، "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 میں استعمال نہیں ہونا چاہیے۔ کلید صرف ایک نام کے تحت موجود ہونی چاہیے۔ میزبان کلید کا سرٹیفکیٹ استعمال نہیں کیا جانا چاہیے؛ معروف_ہوسٹس میں میزبان کے نام سے ماسک استعمال نہیں کرنا چاہئے؛ VerifyHostKeyDNS ترتیب کو غیر فعال کرنا ضروری ہے۔ UserKnownHostsFile پیرامیٹر کا فعال ہونا ضروری ہے۔
منتقلی کے لیے تجویز کردہ الگورتھم میں RFC2 RSA SHA-256 کی بنیاد پر rsa-sha512-8332/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-agent ساکٹ تک رسائی حاصل ہو تو ممکنہ طور پر اس کا فائدہ اٹھایا جا سکتا ہے۔ جو چیز استحصال کو مزید مشکل بناتی ہے وہ یہ ہے کہ صرف جڑ اور اصل صارف کو ساکٹ تک رسائی حاصل ہے۔ ممکنہ طور پر حملے کا منظر نامہ یہ ہے کہ ایجنٹ کو ایک ایسے اکاؤنٹ پر ری ڈائریکٹ کیا جاتا ہے جو حملہ آور کے زیر کنٹرول ہے، یا کسی ایسے میزبان کی طرف جہاں حملہ آور کو جڑ تک رسائی حاصل ہے۔
- sshd نے PAM سب سسٹم میں صارف نام کے ساتھ بہت بڑے پیرامیٹرز کو منتقل کرنے کے خلاف تحفظ شامل کیا ہے، جو آپ کو PAM (پلگ ایبل اوتھنٹیکیشن ماڈیول) سسٹم ماڈیولز میں کمزوریوں کو روکنے کی اجازت دیتا ہے۔ مثال کے طور پر، تبدیلی sshd کو سولاریس (CVE-2020-14871) میں حال ہی میں دریافت شدہ جڑ کے خطرے سے فائدہ اٹھانے کے لیے بطور ویکٹر استعمال ہونے سے روکتی ہے۔
- مطابقت کی تبدیلیوں کو ممکنہ طور پر توڑنا:
- ssh اور sshd میں، ایک تجرباتی کلیدی تبادلے کا طریقہ دوبارہ ڈیزائن کیا گیا ہے جو کوانٹم کمپیوٹر پر اندازہ لگانے کے لیے مزاحم ہے۔ کوانٹم کمپیوٹرز ایک قدرتی نمبر کو بنیادی عوامل میں تحلیل کرنے کے مسئلے کو حل کرنے میں بنیادی طور پر تیزی سے کام کرتے ہیں، جو جدید غیر متناسب خفیہ کاری الگورتھم پر مشتمل ہے اور کلاسیکی پروسیسرز پر مؤثر طریقے سے حل نہیں کیا جا سکتا۔ استعمال شدہ طریقہ NTRU پرائم الگورتھم پر مبنی ہے، جو پوسٹ کوانٹم کرپٹو سسٹمز کے لیے تیار کیا گیا ہے، اور X25519 بیضوی وکر کلیدی تبادلہ طریقہ۔ کے بجائے [ای میل محفوظ] طریقہ اب کے طور پر شناخت کیا جاتا ہے [ای میل محفوظ] (sntrup4591761 الگورتھم کو sntrup761 سے بدل دیا گیا ہے)۔
- ssh اور sshd میں، جس ترتیب میں تعاون یافتہ ڈیجیٹل دستخطی الگورتھم کا اعلان کیا جاتا ہے اسے تبدیل کر دیا گیا ہے۔ ED25519 اب ECDSA کے بجائے پہلے پیش کیا جاتا ہے۔
- ssh اور sshd میں، انٹرایکٹو سیشنز کے لیے TOS/DSCP کوالٹی آف سروس پیرامیٹرز کو سیٹ کرنا اب TCP کنکشن قائم کرنے سے پہلے کیا جاتا ہے۔
- سائفر سپورٹ کو ssh اور sshd میں بند کر دیا گیا ہے۔ [ای میل محفوظ]، جو aes256-cbc سے مماثل ہے اور RFC-4253 کی منظوری سے پہلے استعمال کیا گیا تھا۔
- پہلے سے طے شدہ طور پر، CheckHostIP پیرامیٹر غیر فعال ہے، جس کا فائدہ نہ ہونے کے برابر ہے، لیکن اس کا استعمال لوڈ بیلنسرز کے پیچھے میزبانوں کے لیے کلیدی گردش کو نمایاں طور پر پیچیدہ بناتا ہے۔
- PerSourceMaxStartups اور PerSourceNetBlockSize سیٹنگز کو sshd میں شامل کیا گیا ہے تاکہ کلائنٹ ایڈریس کی بنیاد پر ہینڈلرز کو لانچ کرنے کی شدت کو محدود کیا جا سکے۔ یہ پیرامیٹرز آپ کو عام MaxStartups ترتیب کے مقابلے پراسیس کے آغاز پر حد کو زیادہ باریک کنٹرول کرنے کی اجازت دیتے ہیں۔
- ssh اور sshd میں ایک نئی LogVerbose ترتیب شامل کی گئی ہے، جو آپ کو ٹیمپلیٹس، فنکشنز اور فائلوں کے ذریعے فلٹر کرنے کی صلاحیت کے ساتھ لاگ میں ڈالی گئی ڈیبگنگ معلومات کی سطح کو زبردستی بڑھانے کی اجازت دیتی ہے۔
- ssh میں، ایک نئی میزبان کلید کو قبول کرتے وقت، کلید سے وابستہ تمام میزبان نام اور IP پتے دکھائے جاتے ہیں۔
- ssh میزبان کیز کی شناخت کرتے وقت UserKnownHostsFile=none آپشن کو know_hosts فائل کے استعمال کو غیر فعال کرنے کی اجازت دیتا ہے۔
- ایک KnownHostsCommand ترتیب ssh کے لیے ssh_config میں شامل کر دی گئی ہے، جس سے آپ کو مخصوص کمانڈ کے آؤٹ پٹ سے know_hosts ڈیٹا حاصل کرنے کی اجازت ملتی ہے۔
- SOCKS کے ساتھ RemoteForward آپشن کا استعمال کرتے وقت آپ کو منزل تک محدود کرنے کی اجازت دینے کے لیے ssh_config میں PermitRemoteOpen آپشن شامل کیا گیا۔
- FIDO کیز کے لیے ssh میں، غلط PIN کی وجہ سے ڈیجیٹل دستخطی آپریشن کی ناکامی کی صورت میں ایک بار بار پن کی درخواست فراہم کی جاتی ہے اور صارف کو PIN کا اشارہ نہیں دیا جاتا ہے (مثال کے طور پر، جب صحیح بایومیٹرک ڈیٹا حاصل نہیں کیا جا سکا اور آلہ دستی پن کے اندراج پر واپس آ گیا)۔
- sshd لینکس پر seccomp-bpf پر مبنی عمل تنہائی کے طریقہ کار میں اضافی سسٹم کالز کے لیے تعاون شامل کرتا ہے۔
- contrib/ssh-copy-id افادیت کو اپ ڈیٹ کر دیا گیا ہے۔
ماخذ: opennet.ru