چار ماہ کی ترقی کے بعد رہائی SSH 2.0 اور SFTP پروٹوکول کے ذریعے کام کرنے کے لیے ایک کھلا کلائنٹ اور سرور کا نفاذ۔
OpenSSH 8.2 کے اجراء میں ایک اہم بہتری پروٹوکول کو سپورٹ کرنے والے آلات کا استعمال کرتے ہوئے دو عنصر کی توثیق کرنے کی صلاحیت تھی۔ ، اتحاد کی طرف سے تیار کیا گیا ہے . U2F کم لاگت والے ہارڈویئر ٹوکن بنانے کی اجازت دیتا ہے تاکہ صارف کی جسمانی موجودگی کی تصدیق کی جا سکے، ان کے ساتھ USB، بلوٹوتھ یا NFC کے ذریعے بات چیت کی جا سکے۔ اس طرح کے آلات کو ویب سائٹس پر دو عنصر کی تصدیق کے ذریعہ پروموٹ کیا جاتا ہے، پہلے ہی بڑے براؤزرز کی طرف سے تعاون کیا جاتا ہے اور مختلف مینوفیکچررز کے ذریعہ تیار کیا جاتا ہے، بشمول Yubico، Feitian، Thetis اور Kensington.
ایسے آلات کے ساتھ بات چیت کرنے کے لیے جو صارف کی موجودگی کی تصدیق کرتے ہیں، نئی کلیدی اقسام "ecdsa-sk" اور "ed25519-sk" کو OpenSSH میں شامل کیا گیا ہے، جو SHA-25519 ہیش کے ساتھ مل کر ECDSA اور Ed256 ڈیجیٹل دستخطی الگورتھم استعمال کرتے ہیں۔ ٹوکنز کے ساتھ تعامل کے طریقہ کار کو ایک انٹرمیڈیٹ لائبریری میں رکھا جاتا ہے، جو PKCS#11 سپورٹ کے لیے لائبریری میں اسی طرح سے لوڈ ہوتا ہے اور لائبریری کے اوپر ایک ریپر ہوتا ہے۔ ، جو USB پر ٹوکنز کے ساتھ بات چیت کرنے کے لیے ٹولز فراہم کرتا ہے (FIDO U2F/CTAP 1 اور FIDO 2.0/CTAP 2 پروٹوکول تعاون یافتہ ہیں)۔ انٹرمیڈیٹ لائبریری libsk-libfido2 OpenSSH ڈویلپرز کے ذریعہ تیار کی گئی ہے۔ بنیادی libfido2 میں، ساتھ ساتھ اوپن بی ایس ڈی کے لیے۔
ایک کلید کی تصدیق اور تخلیق کرنے کے لیے، آپ کو ترتیبات میں "SecurityKeyProvider" پیرامیٹر کی وضاحت کرنا ہوگی یا SSH_SK_PROVIDER ماحولیاتی متغیر کو سیٹ کرنا ہوگا، جو بیرونی لائبریری libsk-libfido2.so (ایکسپورٹ SSH_SK_PROVIDER=/path/to/libdo. تو)۔ پرت لائبریری (--with-security-key-builtin) کے لیے بلٹ ان سپورٹ کے ساتھ openssh بنانا ممکن ہے، اس صورت میں آپ کو "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 ریلیز کو چلانے والے سسٹمز پر کام کرنے کے لیے (مسئلہ پر کام کرنے کے لیے جب دستخط تیار کرتے ہوئے، آپ واضح طور پر "ssh-keygen -t ssh-rsa" کی وضاحت کر سکتے ہیں یا ecdsa-sha2-nistp256/384/521 الگورتھم استعمال کر سکتے ہیں، جو OpenSSH 5.7 سے تعاون یافتہ ہے)۔
دیگر تبدیلیاں:
- sshd_config میں شامل کرنے کی ہدایت شامل کی گئی ہے، جو آپ کو کنفیگریشن فائل کی موجودہ پوزیشن پر دیگر فائلوں کے مواد کو شامل کرنے کی اجازت دیتی ہے (فائل کا نام بتاتے وقت گلوب ماسک استعمال کیے جا سکتے ہیں)؛
- ssh-keygen میں "no-touch-required" آپشن شامل کر دیا گیا ہے، جو کلید تیار کرتے وقت ٹوکن تک رسائی کی جسمانی طور پر تصدیق کرنے کی ضرورت کو غیر فعال کر دیتا ہے۔
- ایک PubkeyAuthOptions ہدایت sshd_config میں شامل کی گئی ہے، جو عوامی کلید کی تصدیق سے متعلق مختلف اختیارات کو یکجا کرتی ہے۔ فی الحال، ٹوکن کی توثیق کے لیے جسمانی موجودگی کی جانچ پڑتال کو چھوڑنے کے لیے صرف "نان-ٹچ-ضرورت" پرچم کی حمایت کی جاتی ہے۔ مشابہت کے مطابق، "no-touch-required" آپشن کو authorized_keys فائل میں شامل کر دیا گیا ہے۔
- ssh-keygen میں "-O write-attestation=/path" اختیار شامل کیا گیا تاکہ کلیدیں تیار کرتے وقت اضافی 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" بلڈ آپشن شامل کر دیا گیا؛
- RFC4253 کی ضرورت کے مطابق، کنکشن کے دوران دکھائے جانے والے بینر میں MaxStartups کی حد سے تجاوز کرنے کی وجہ سے رسائی کو مسدود کرنے کے بارے میں ایک انتباہ فراہم کیا گیا ہے۔ تشخیص کو آسان بنانے کے لیے، sshd پروسیس ہیڈر، جو ps یوٹیلیٹی کا استعمال کرتے وقت نظر آتا ہے، اب فی الحال تصدیق شدہ کنکشنز کی تعداد اور MaxStartups کی حد کی حیثیت دکھاتا ہے۔
- ssh اور ssh-agent میں، اسکرین پر دعوت نامہ دکھانے کے لیے کسی پروگرام کو کال کرتے وقت، $SSH_ASKPASS کے ذریعے مخصوص کیا جاتا ہے، اب دعوت کی قسم کے ساتھ ایک جھنڈا بھی منتقل کیا جاتا ہے: "تصدیق" - تصدیقی ڈائیلاگ (ہاں/نہیں)، "کوئی نہیں " - معلوماتی پیغام، "خالی" - پاس ورڈ کی درخواست؛
- ssh-keygen میں ایک نیا ڈیجیٹل دستخط آپریشن "find-principals" شامل کیا گیا تاکہ ایک مخصوص ڈیجیٹل دستخط سے وابستہ صارف کے لیے اجازت یافتہ دستخط کرنے والی فائل کو تلاش کیا جا سکے۔
- seccomp میکانزم کا استعمال کرتے ہوئے لینکس پر sshd عمل کی تنہائی کے لیے بہتر سپورٹ: IPC سسٹم کالز کو غیر فعال کرنا، clock_gettime64()، clock_nanosleep_time64 اور clock_nanosleep() کی اجازت دینا۔
ماخذ: opennet.ru