چار ماہ کی ترقی کے بعد، OpenSSH 8.7 کی ریلیز، SSH 2.0 اور SFTP پروٹوکول پر کام کرنے کے لیے کلائنٹ اور سرور کا کھلا نفاذ، پیش کیا گیا۔
اہم تبدیلیاں:
- روایتی SCP/RCP پروٹوکول کی بجائے SFTP پروٹوکول کا استعمال کرتے ہوئے scp میں تجرباتی ڈیٹا ٹرانسفر موڈ شامل کیا گیا ہے۔ SFTP نام سے ہینڈلنگ کے زیادہ متوقع طریقے استعمال کرتا ہے اور دوسرے میزبان کی طرف گلوب پیٹرن کی شیل پروسیسنگ کا استعمال نہیں کرتا، جس سے سیکیورٹی کے مسائل پیدا ہوتے ہیں۔ scp میں SFTP کو فعال کرنے کے لیے، "-s" جھنڈا تجویز کیا گیا ہے، لیکن مستقبل میں اس پروٹوکول کو بطور ڈیفالٹ تبدیل کرنے کا منصوبہ ہے۔
- sftp-server ~/ اور ~user/ راستوں کو بڑھانے کے لیے SFTP پروٹوکول میں ایکسٹینشن لاگو کرتا ہے، جو scp کے لیے ضروری ہے۔
- scp یوٹیلیٹی نے دو ریموٹ ہوسٹس (مثال کے طور پر، "scp host-a:/path host-b:") کے درمیان فائلوں کو کاپی کرتے وقت رویے کو تبدیل کر دیا ہے، جو اب ایک انٹرمیڈیٹ لوکل ہوسٹ کے ذریعے بطور ڈیفالٹ کیا جاتا ہے، جیسا کہ اس کی وضاحت کرتے وقت " -3" جھنڈا۔ یہ نقطہ نظر آپ کو پہلے میزبان کو غیر ضروری اسناد دینے سے بچنے کی اجازت دیتا ہے اور شیل میں فائل کے ناموں کی ٹرپل تشریح (ماخذ، منزل اور مقامی نظام کی طرف)، اور SFTP استعمال کرتے وقت، یہ آپ کو ریموٹ تک رسائی حاصل کرتے وقت تصدیق کے تمام طریقے استعمال کرنے کی اجازت دیتا ہے۔ میزبان، اور نہ صرف غیر انٹرایکٹو طریقے۔ پرانے رویے کو بحال کرنے کے لیے "-R" آپشن شامل کر دیا گیا ہے۔
- ForkAfterAuthentication سیٹنگ کو "-f" جھنڈے کے مطابق ssh میں شامل کیا گیا۔
- StdinNull ترتیب کو ssh میں شامل کیا گیا، جو "-n" جھنڈے کے مطابق ہے۔
- ssh میں ایک SessionType سیٹنگ شامل کر دی گئی ہے، جس کے ذریعے آپ "-N" (کوئی سیشن نہیں) اور "-s" (سب سسٹم) جھنڈوں کے مطابق موڈ سیٹ کر سکتے ہیں۔
- ssh-keygen آپ کو کلیدی فائلوں میں کلیدی درستگی کا وقفہ بتانے کی اجازت دیتا ہے۔
- sshsig دستخط کے حصے کے طور پر مکمل عوامی کلید پرنٹ کرنے کے لیے ssh-keygen میں "-Oprint-pubkey" جھنڈا شامل کیا گیا۔
- ssh اور sshd میں، کلائنٹ اور سرور دونوں کو ایک زیادہ محدود کنفیگریشن فائل پارسر استعمال کرنے کے لیے منتقل کر دیا گیا ہے جو قیمتوں، خالی جگہوں، اور فرار کے حروف کو سنبھالنے کے لیے شیل جیسے اصول استعمال کرتا ہے۔ نیا تجزیہ کار پہلے کیے گئے مفروضوں کو بھی نظر انداز نہیں کرتا ہے، جیسے کہ اختیارات میں دلائل کو چھوڑنا (مثال کے طور پر، DenyUsers کی ہدایت کو مزید خالی نہیں چھوڑا جا سکتا ہے)، غیر بند اقتباسات، اور متعدد = حروف کی وضاحت کرنا۔
- کلیدوں کی تصدیق کرتے وقت SSHFP DNS ریکارڈز کا استعمال کرتے ہوئے، ssh اب تمام مماثل ریکارڈز کو چیک کرتا ہے، نہ کہ صرف ایک مخصوص قسم کے ڈیجیٹل دستخط والے۔
- ssh-keygen میں، -Ochallenge آپشن کے ساتھ FIDO کلید تیار کرتے وقت، بلٹ ان پرت کو اب libfido2 کے بجائے ہیشنگ کے لیے استعمال کیا جاتا ہے، جو 32 بائٹس سے بڑے یا چھوٹے چیلنج کی ترتیب کے استعمال کی اجازت دیتا ہے۔
- sshd میں، authorized_keys فائلوں میں ماحول="..." ہدایات پر کارروائی کرتے وقت، پہلا میچ اب قبول کیا جاتا ہے اور 1024 ماحولیاتی متغیر ناموں کی ایک حد ہے۔
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 میں پہلے سے طے شدہ طور پر 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 سے تعاون یافتہ)۔
ماخذ: opennet.ru