انتشار OpenSSH 8.2 با پشتیبانی از توکن های احراز هویت دو مرحله ای FIDO/U2F

پس از چهار ماه توسعه ارایه شده رهایی OpenSSH 8.2، یک پیاده سازی باز از کلاینت و سرور برای کار بر روی پروتکل های SSH 2.0 و SFTP.

یکی از پیشرفت‌های کلیدی در انتشار OpenSSH 8.2، امکان استفاده از احراز هویت دو مرحله‌ای با دستگاه‌هایی است که از پروتکل پشتیبانی می‌کنند. U2F، توسعه یافته توسط اتحاد فیدو. U2F به شما امکان می دهد تا توکن های سخت افزاری کم هزینه ای را برای تأیید حضور فیزیکی کاربر ایجاد کنید، که تعامل با آنها از طریق USB، بلوتوث یا NFC انجام می شود. این دستگاه‌ها به‌عنوان ابزاری برای احراز هویت دو مرحله‌ای در وب‌سایت‌ها تبلیغ می‌شوند، قبلاً توسط مرورگرهای اصلی پشتیبانی می‌شوند و از تولیدکنندگان مختلف از جمله Yubico، Feitian، Thetis و Kensington در دسترس هستند.

برای تعامل با دستگاه‌هایی که حضور کاربر را تأیید می‌کنند، OpenSSH انواع کلیدهای جدید "ecdsa-sk" و "ed25519-sk" را اضافه کرد که از الگوریتم‌های امضای دیجیتال ECDSA و Ed25519 در ترکیب با هش SHA-256 استفاده می‌کنند. رویه‌های تعامل با توکن‌ها به یک کتابخانه میانی منتقل می‌شوند که به طور مشابه با کتابخانه برای پشتیبانی PKCS # 11 بارگیری می‌شود و یک اتصال بر روی کتابخانه است. libfido2، که ابزاری برای برقراری ارتباط با توکن ها از طریق USB فراهم می کند (پشتیبانی از پروتکل های FIDO U2F/CTAP 1 و FIDO 2.0/CTAP 2). تهیه شده توسط توسعه دهندگان OpenSSH، کتابخانه میانی libsk-libfido2 مشمول به ترکیب اصلی libfido2، مانند درایور HID برای OpenBSD

برای احراز هویت و تولید کلید، باید پارامتر "SecurityKeyProvider" را در تنظیمات مشخص کنید یا متغیر محیطی SSH_SK_PROVIDER را تنظیم کنید و مسیر کتابخانه خارجی libsk-libfido2.so را مشخص کنید (صادرات SSH_SK_PROVIDER=/path/to/libsk-libfido2.so.so ). ساخت openssh با پشتیبانی داخلی برای کتابخانه بین لایه (--with-security-key-builtin) امکان پذیر است، در این صورت باید پارامتر "SecurityKeyProvider=internal" را تنظیم کنید.
در مرحله بعد، باید "ssh-keygen -t ecdsa-sk" را اجرا کنید یا اگر کلیدها قبلا ایجاد و پیکربندی شده اند، با استفاده از "ssh" به سرور متصل شوید. هنگام اجرای ssh-keygen، جفت کلید تولید شده در "~/.ssh/id_ecdsa_sk" ذخیره می شود و می تواند مانند کلیدهای دیگر استفاده شود.

کلید عمومی (id_ecdsa_sk.pub) باید در فایل authorized_keys در سرور کپی شود. در سمت سرور، فقط امضای دیجیتال بررسی می‌شود و تعامل با توکن‌ها در سمت کلاینت انجام می‌شود (libsk-libfido2 نیازی به نصب روی سرور ندارد، اما سرور باید از نوع کلید "ecdsa-sk" پشتیبانی کند) . کلید خصوصی تولید شده (id_ecdsa_sk) اساساً یک توصیفگر کلید است که یک کلید واقعی را فقط در ترکیب با دنباله مخفی ذخیره شده در کنار توکن U2F تشکیل می دهد. اگر کلید id_ecdsa_sk به دست مهاجم بیفتد، برای عبور از احراز هویت، باید به یک توکن سخت افزاری نیز دسترسی پیدا کند که بدون آن کلید خصوصی ذخیره شده در فایل id_ecdsa_sk بی فایده است.

علاوه بر این، به طور پیش فرض، هنگام انجام هرگونه عملیات با کلیدها (هم در طول تولید و هم در حین احراز هویت)، تأیید محلی حضور فیزیکی کاربر مورد نیاز است، به عنوان مثال، پیشنهاد می شود سنسور روی نشانه را لمس کنید، که کار را دشوار می کند. انجام حملات از راه دور به سیستم ها با یک توکن متصل. به عنوان خط دفاعی دیگر، مرحله راه اندازی ssh-keygen نیز می تواند رمز عبور برای دسترسی به فایل کلید داده شود.

نسخه جدید OpenSSH همچنین اعلام کرد که الگوریتم هایی با استفاده از هش های SHA-1 به زودی از بین می روند. ترویج اثربخشی حملات برخورد با یک پیشوند معین (هزینه انتخاب یک برخورد حدود 45 هزار دلار برآورد شده است). در یکی از نسخه های آینده، آنها قصد دارند به طور پیش فرض قابلیت استفاده از الگوریتم امضای دیجیتال کلید عمومی ssh-rsa را غیرفعال کنند، که در RFC اصلی برای پروتکل SSH ذکر شده است و در عمل گسترده است (برای بررسی استفاده از ssh -rsa در سیستم های خود، می توانید سعی کنید از طریق ssh با گزینه "-oHostKeyAlgorithms=-ssh-rsa" متصل شوید).

برای هموار کردن انتقال به الگوریتم‌های جدید در OpenSSH، در یکی از نسخه‌های بعدی، تنظیمات UpdateHostKeys به طور پیش‌فرض فعال می‌شود که به‌طور خودکار کلاینت‌ها را به الگوریتم‌های مطمئن‌تر منتقل می‌کند. الگوریتم های توصیه شده برای مهاجرت عبارتند از rsa-sha2-256/512 بر اساس RFC8332 RSA SHA-2 (پشتیبانی شده از OpenSSH 7.2 و به طور پیش فرض استفاده می شود)، ssh-ed25519 (پشتیبانی از OpenSSH 6.5) و ecdsa-sha2-nistp256/384 مبتنی بر ecdsa-sha521-nistp5656/5.7 در RFCXNUMX ECDSA (پشتیبانی از OpenSSH XNUMX).

در OpenSSH 8.2، امکان اتصال با استفاده از "ssh-rsa" هنوز در دسترس است، اما این الگوریتم از لیست CASignatureAlgorithms حذف شده است، که الگوریتم های مجاز برای امضای دیجیتالی گواهی های جدید را تعریف می کند. به طور مشابه، الگوریتم diffie-helman-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 پشتیبانی می‌شوند.

سایر تغییرات:

• دستور Include به sshd_config اضافه شده است که به شما امکان می دهد محتویات فایل های دیگر را در موقعیت فعلی فایل پیکربندی قرار دهید (ماسک های glob در هنگام تعیین نام فایل مجاز هستند).
• گزینه "بدون نیاز به لمس" به ssh-keygen اضافه شده است که نیاز به تایید فیزیکی دسترسی به نشانه را هنگام تولید کلید غیرفعال می کند.
• دستور PubkeyAuthOptions را به sshd_config اضافه کرد تا گزینه های مختلف مربوط به احراز هویت کلید عمومی را ترکیب کند. در حال حاضر، برای رد شدن از بررسی حضور فیزیکی هنگام احراز هویت با یک نشانه، فقط پرچم "بدون نیاز به لمس" پشتیبانی می شود. بر اساس قیاس، گزینه "no-touch-required" به فایل authorized_keys اضافه شده است.
• گزینه "-O write-attestation=/path" به ssh-keygen اضافه شد تا گواهینامه های تایید FIDO اضافی هنگام تولید کلیدها بنویسد. OpenSSH هنوز از این گواهی‌ها استفاده نمی‌کند، اما بعداً می‌توان از آنها برای تأیید قرار گرفتن کلید در یک فروشگاه سخت‌افزاری مورد اعتماد استفاده کرد.
• در تنظیمات ssh و sshd از طریق دستورالعمل IPQoS، اکنون امکان تنظیم حالت اولویت بندی ترافیک وجود دارد. LE DSCP (رفتار با تلاش کمتر در هر هاپ)؛
• در ssh، هنگام تنظیم مقدار "AddKeysToAgent=yes"، اگر کلید حاوی یک فیلد با نظر نباشد، به ssh-agent با مسیر کلید به عنوان نظر اضافه می شود. که در
  ssh-keygen و ssh-agent نیز اکنون از تگ‌های PKCS#11 و نام موضوع X.509 به‌جای مسیر کتابخانه به‌عنوان نظرات در کلید استفاده می‌کنند.

• اضافه شدن قابلیت صادرات PEM برای کلیدهای DSA و ECDSA به ssh-keygen.
• یک ssh-sk-helper اجرایی جدید اضافه شد که برای جداسازی کتابخانه دسترسی نشانه FIDO/U2F استفاده می‌شود.
• گزینه ساخت "--with-zlib" به ssh و sshd برای کامپایل با پشتیبانی از کتابخانه zlib اضافه شد.
• مطابق با الزامات RFC4253، بنر نمایش داده شده در هنگام اتصال با هشداری در مورد مسدود شدن دسترسی به دلیل فراتر رفتن از محدودیت های MaxStartups ارائه می شود. برای ساده‌سازی تشخیص، هدر فرآیند sshd که هنگام استفاده از ابزار ps قابل مشاهده است، تعداد اتصالات تأیید شده فعلی و وضعیت محدودیت MaxStartups را نشان می‌دهد.
• در ssh و ssh-agent، هنگام فراخوانی یک برنامه برای نمایش یک مجموعه درخواست از طریق $SSH_ASKPASS، اکنون یک پرچم با نوع اعلان ارسال می شود: "تأیید" - گفتگوی تایید (بله / خیر)، "هیچ" - پیام اطلاعاتی، "خالی" - درخواست رمز عبور؛
• یک عملیات امضای دیجیتال جدید "find-principals" را به ssh-keygen اضافه کرد تا فایل مجاز امضاکنندگان را برای کاربر مرتبط با امضای دیجیتال مشخص شده جستجو کند.
• پشتیبانی بهبودیافته برای جداسازی فرآیند sshd در لینوکس با استفاده از مکانیزم seccomp: غیرفعال کردن تماس‌های سیستم IPC، اجازه دادن به clock_gettime64()، clock_nanosleep_time64 و clock_nanosleep().

منبع: opennet.ru