اوپن ایس ایس ایچ 8.2 FIDO/U2F ٹو فیکٹر توثیق ٹوکن کے لیے سپورٹ کے ساتھ جاری کیا گیا

چار ماہ کی ترقی کے بعد پیش کیا رہائی اوپن ایس ایچ ایکس این ایم ایکسSSH 2.0 اور SFTP پروٹوکول کے ذریعے کام کرنے کے لیے ایک کھلا کلائنٹ اور سرور کا نفاذ۔

OpenSSH 8.2 ریلیز میں ایک اہم بہتری پروٹوکول کو سپورٹ کرنے والے آلات کے ساتھ دو عنصر کی توثیق کو استعمال کرنے کی صلاحیت تھی۔ U2F، اتحاد کی طرف سے تیار کیا گیا ہے FIDOU2F کم لاگت والے ہارڈویئر ٹوکنز کی تخلیق کو قابل بناتا ہے تاکہ صارف کی جسمانی موجودگی کی تصدیق کی جا سکے، USB، بلوٹوتھ یا NFC کے ذریعے ان کے ساتھ بات چیت کی جا سکے۔ ان آلات کو ویب سائٹس پر دو عنصر کی تصدیق کے ذریعہ پروموٹ کیا جاتا ہے، پہلے ہی بڑے براؤزرز کی طرف سے تعاون کیا جاتا ہے، اور مختلف مینوفیکچررز بشمول Yubico، Feitian، Thetis، اور Kensington کے ذریعہ تیار کیا جاتا ہے۔

ایسے آلات کے ساتھ تعامل کرنے کے لیے جو صارف کی موجودگی کی تصدیق کرتے ہیں، OpenSSH نے نئی کلیدی اقسام، "ecdsa-sk" اور "ed25519-sk" کو شامل کیا ہے جو SHA-256 ہیش کے ساتھ مل کر ECDSA اور Ed25519 ڈیجیٹل دستخطی الگورتھم استعمال کرتے ہیں۔ ٹوکنز کے ساتھ تعامل کے طریقہ کار کو ایک انٹرمیڈیٹ لائبریری میں منتقل کر دیا گیا ہے، جو PKCS#11 سپورٹ لائبریری کی طرح بھری ہوئی ہے اور لائبریری کے ارد گرد ایک ریپر کے طور پر کام کرتی ہے۔ libfido2، جو USB پر ٹوکنز کے ساتھ بات چیت کرنے کے ذرائع فراہم کرتا ہے (FIDO U2F/CTAP 1 اور FIDO 2.0/CTAP 2 پروٹوکول تعاون یافتہ ہیں)۔ libsk-libfido2 انٹرمیڈیٹ لائبریری، OpenSSH ڈویلپرز کے ذریعہ تیار کی گئی ہے، شامل libfido2 کی بنیادی ساخت میں، ساتھ ساتھ HID ڈرائیور اوپن بی ایس ڈی کے لیے۔

ایک کلید کی تصدیق اور تخلیق کرنے کے لیے، آپ کو ترتیبات میں "SecurityKeyProvider" پیرامیٹر کی وضاحت کرنا ہوگی یا SSH_SK_PROVIDER ماحولیاتی متغیر کو سیٹ کرنا ہوگا، بیرونی لائبریری libsk-libfido2.so (ایکسپورٹ SSH_SK_PROVIDER=/sk_provider=/sk-libfido2.so) کا راستہ بتانا ہوگا۔ OpenSSH انٹرمیڈیری لائبریری کے لیے بلٹ ان سپورٹ کے ساتھ بنایا جا سکتا ہے (--with-security-key-builtin)؛ اس صورت میں، آپ کو "SecurityKeyProvider=internal" پیرامیٹر سیٹ کرنا ہوگا۔
اس کے بعد، "ssh-keygen -t ecdsa-sk" چلائیں یا، اگر چابیاں پہلے ہی بنائی اور کنفیگر ہو چکی ہیں، تو "ssh" کا استعمال کرتے ہوئے سرور سے جڑیں۔ جب آپ ssh-keygen چلاتے ہیں، تو تیار کردہ کلید کا جوڑا "~/.ssh/id_ecdsa_sk" میں محفوظ ہو جائے گا اور اسے دوسری کلیدوں کی طرح استعمال کیا جا سکتا ہے۔

عوامی کلید (id_ecdsa_sk.pub) کو سرور پر مجاز_کیز فائل میں کاپی کیا جانا چاہیے۔ سرور صرف ڈیجیٹل دستخط کی تصدیق کرتا ہے، جبکہ کلائنٹ پر ٹوکن تعامل ہوتا ہے (libsk-libfido2 کو سرور پر انسٹال کرنے کی ضرورت نہیں ہے، لیکن سرور کو "ecdsa-sk" کلیدی قسم کی حمایت کرنی چاہیے)۔ تیار کردہ نجی کلید (id_ecdsa_sk) بنیادی طور پر ایک کلیدی وضاحت کنندہ ہے جو صرف U2F ٹوکن پر محفوظ کردہ خفیہ ترتیب کے ساتھ مل کر ہی حقیقی کلید بناتی ہے۔ اگر کوئی حملہ آور id_ecdsa_sk کلید حاصل کرتا ہے، تو اسے تصدیق کرنے کے لیے ہارڈویئر ٹوکن تک بھی رسائی کی ضرورت ہوگی، جس کے بغیر id_ecdsa_sk فائل میں محفوظ کردہ نجی کلید بیکار ہے۔

مزید برآں، بطور ڈیفالٹ، تمام کلیدی آپریشنز (جنریشن اور توثیق دونوں) کے لیے صارف کی جسمانی موجودگی کی مقامی تصدیق کی ضرورت ہوتی ہے، جیسے ٹوکن پر سینسر کو چھونا، جس سے مربوط ٹوکن والے سسٹمز پر ریموٹ حملے کرنا مشکل ہو جاتا ہے۔ سیکیورٹی کی ایک اضافی پرت کے طور پر، کلیدی فائل تک رسائی کے لیے پاس ورڈ بھی ssh-keygen اسٹارٹ اپ کے دوران سیٹ کیا جا سکتا ہے۔

OpenSSH کے نئے ورژن نے SHA-1 ہیشز کا استعمال کرتے ہوئے الگورتھم کی آئندہ فرسودگی کا بھی اعلان کیا اضافہ دیئے گئے سابقہ ​​کے ساتھ تصادم کے حملوں کی تاثیر (تصادم کے انتخاب کی لاگت کا تخمینہ تقریباً 45 ہزار ڈالر ہے)۔ آنے والی ریلیز میں سے ایک میں، وہ عوامی کلیدی ڈیجیٹل دستخطی الگورتھم "ssh-rsa" کو استعمال کرنے کی صلاحیت کو بطور ڈیفالٹ غیر فعال کرنے کا ارادہ رکھتے ہیں، جس کا تذکرہ SSH پروٹوکول کے لیے اصل RFC میں کیا گیا ہے اور عملی طور پر وسیع پیمانے پر رہتا ہے (استعمال کی جانچ کرنے کے لیے۔ آپ کے سسٹمز میں ssh-rsa کے، آپ ssh کے ذریعے آپشن "-oHostKeyAlgorithms=-ssh-rsa") کے ساتھ جڑنے کی کوشش کر سکتے ہیں۔

OpenSSH میں نئے الگورتھم کی منتقلی کو ہموار کرنے کے لیے، مستقبل کی ریلیز میں UpdateHostKeys کی ترتیب بطور ڈیفالٹ فعال ہو جائے گی، جو خود بخود کلائنٹس کو زیادہ قابل اعتماد الگورتھم میں منتقل کر دے گی۔ منتقلی کے لیے تجویز کردہ الگورتھم میں 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 سے تعاون یافتہ)۔

OpenSSH 8.2 اب بھی "ssh-rsa" کا استعمال کرتے ہوئے منسلک کرنے کی حمایت کرتا ہے، لیکن اس الگورتھم کو CASignatureAlgorithms کی فہرست سے ہٹا دیا گیا ہے، جو نئے سرٹیفکیٹس پر ڈیجیٹل طور پر دستخط کرنے کے لیے اجازت یافتہ الگورتھم کی وضاحت کرتا ہے۔ اسی طرح، diffie-hellman-group14-sha1 الگورتھم کو تعاون یافتہ ڈیفالٹ کلیدی تبادلہ الگورتھم سے ہٹا دیا گیا ہے۔ یہ نوٹ کیا جاتا ہے کہ سرٹیفکیٹس میں SHA-1 کا استعمال ایک اضافی خطرہ رکھتا ہے، کیونکہ حملہ آور کے پاس موجودہ سرٹیفکیٹ کے لیے تصادم تلاش کرنے کے لیے لامحدود وقت ہوتا ہے، جب کہ میزبان کیز پر حملے کنکشن ٹائم آؤٹ (LoginGraceTime) کے ذریعے محدود ہوتے ہیں۔

ssh-keygen چلاتے وقت، rsa-sha2-512 الگورتھم، جو OpenSSH 7.2 سے تعاون یافتہ ہے، اب بطور ڈیفالٹ استعمال کیا جاتا ہے، جو OpenSSH 8.2 کے دستخط شدہ سرٹیفکیٹس کو پرانے OpenSSH ریلیز کو چلانے والے سسٹمز پر کارروائی کرنے کی کوشش کرتے وقت مطابقت کے مسائل پیدا کر سکتا ہے (اس مسئلے پر کام کرنے کے لیے، آپ واضح طور پر وضاحت کر سکتے ہیں-" دستخط، یا OpenSSH 5.7 سے تعاون یافتہ ecdsa-sha2-nistp256/384/521 الگورتھم استعمال کریں۔

دیگر تبدیلیاں:

• شامل کرنے کی ہدایت کو sshd_config میں شامل کیا گیا ہے، جس سے دیگر فائلوں کے مواد کو کنفیگریشن فائل کی موجودہ پوزیشن میں شامل کیا جا سکتا ہے (فائل کا نام بتاتے وقت گلوب ماسک استعمال کیے جا سکتے ہیں)؛
• ssh-keygen میں "no-touch-required" آپشن شامل کر دیا گیا ہے، جو کلید تیار کرتے وقت ٹوکن تک رسائی کی فزیکل تصدیق کی ضرورت کو غیر فعال کر دیتا ہے۔
• PubkeyAuthOptions کی ہدایت کو sshd_config میں شامل کر دیا گیا ہے، جس سے عوامی کلید کی توثیق سے متعلق مختلف اختیارات کو یکجا کیا گیا ہے۔ فی الحال، ٹوکن کی توثیق کے دوران جسمانی موجودگی کی جانچ کو چھوڑنے کی اجازت دیتے ہوئے، صرف "نان ٹچ-ضرورت" پرچم کی حمایت کی جاتی ہے۔ اسی طرح، "no-touch-required" آپشن کو authorized_keys فائل میں شامل کیا گیا ہے۔
• "-O write-attestation=/path" آپشن ssh-keygen میں شامل کر دیا گیا ہے، جس سے کلیدیں تیار کرتے وقت اضافی FIDO تصدیقی سرٹیفکیٹ لکھے جا سکتے ہیں۔ OpenSSH فی الحال ان سرٹیفیکیٹس کا استعمال نہیں کرتا ہے، لیکن ان کا استعمال مستقبل میں اس بات کی تصدیق کے لیے کیا جا سکتا ہے کہ کلید قابل اعتماد ہارڈویئر اسٹوریج میں محفوظ ہے۔
• ssh اور sshd سیٹنگز میں، اب IPQoS ڈائریکٹیو کے ذریعے ٹریفک کی ترجیحی موڈ کو سیٹ کرنا ممکن ہے۔ ایل ای ڈی ایس سی پی (نچلی کوشش فی ہاپ رویہ)؛
• ssh میں، "AddKeysToAgent=yes" ویلیو سیٹ کرتے وقت، اگر کلید میں تبصرہ کا فیلڈ شامل نہیں ہے، تو اسے ssh-agent میں شامل کر دیا جائے گا جس میں ایک تبصرہ کے طور پر بیان کی گئی کلید کا راستہ ہے۔
  ssh-keygen اور ssh-agent اب PKCS#11 لیبلز اور X.509 موضوع کا نام بھی لائبریری کے راستے کی بجائے کلید میں تبصرے کے طور پر استعمال کرتے ہیں۔
• ssh-keygen میں DSA اور ECDSA کیز کے لیے PEM برآمد کرنے کی صلاحیت شامل کی گئی ہے۔
• ایک نئی قابل عمل فائل شامل کی گئی ssh-sk-helper، جو FIDO/U2F ٹوکنز تک لائبریری کی رسائی کو الگ کرنے کے لیے استعمال ہوتی ہے۔
• zlib لائبریری سپورٹ کے ساتھ کمپائلنگ کے لیے ssh اور sshd میں "-with-zlib" بلڈ آپشن شامل کیا گیا۔
• RFC 4253 کے مطابق، MaxStartups کی حد سے تجاوز کرنے کی وجہ سے رسائی بلاک ہونے کے بارے میں ایک انتباہ اب کنکشن بینر میں ظاہر ہوتا ہے۔ تشخیص کو آسان بنانے کے لیے، sshd پروسیس ہیڈر، جو ps یوٹیلیٹی کا استعمال کرتے ہوئے نظر آتا ہے، اب فی الحال تصدیق شدہ کنکشنز کی تعداد اور MaxStartups کی حد کی حیثیت کو ظاہر کرتا ہے۔
• ssh اور ssh-agent میں، اسکرین پر دعوت نامہ دکھانے کے لیے کسی پروگرام کو کال کرتے وقت، $SSH_ASKPASS کے ذریعے مخصوص کیا جاتا ہے، اب دعوت نامہ کی قسم کے ساتھ ایک جھنڈا بھی پاس کیا جاتا ہے: "تصدیق" — تصدیقی ڈائیلاگ (ہاں/نہیں)، "کوئی نہیں" — معلوماتی پیغام، "خالی" — پاس ورڈ کی درخواست؛
• ایک نیا ڈیجیٹل دستخط آپریشن، "فائنڈ پرنسپلز" کو ssh-keygen میں شامل کیا گیا ہے تاکہ مخصوص ڈیجیٹل دستخط سے وابستہ صارف کے لیے اجازت یافتہ دستخط کرنے والی فائل کو تلاش کیا جا سکے۔
• Улучшена поддержка изоляции процесса sshd в Linux при помощи механизма seccomp: запрещены системные вызовы IPC, разрешены clock_gettime64(), clock_nanosleep_time64 и clock_nanosleep().

ماخذ: opennet.ru