پس از چهار ماه توسعه، انتشار OpenSSH 8.7، یک پیاده سازی باز از یک کلاینت و سرور برای کار بر روی پروتکل های SSH 2.0 و SFTP، ارائه شد.
تغییرات اصلی:
- یک حالت انتقال داده آزمایشی با استفاده از پروتکل SFTP به جای پروتکل SCP/RCP سنتی به scp اضافه شده است. SFTP از روش های مدیریت نام قابل پیش بینی تری استفاده می کند و از پردازش پوسته الگوهای glob در سمت میزبان دیگر استفاده نمی کند که مشکلات امنیتی ایجاد می کند. برای فعال کردن SFTP در scp، پرچم "-s" پیشنهاد شده است، اما در آینده برنامه ریزی شده است که به طور پیش فرض به این پروتکل تغییر دهید.
- sftp-server پسوندهای پروتکل SFTP را برای گسترش مسیرهای ~/ و ~user/ پیاده سازی می کند که برای scp ضروری است.
- ابزار scp رفتار را هنگام کپی کردن فایل‌ها بین دو میزبان راه دور تغییر داده است (مثلاً «scp host-a:/path host-b:»)، که اکنون به طور پیش‌فرض از طریق یک میزبان محلی میانی انجام می‌شود، مانند هنگام تعیین « پرچم -3 اینچی این رویکرد به شما امکان می دهد از انتقال اعتبار غیر ضروری به میزبان اول و تفسیر سه گانه نام فایل ها در پوسته (در سمت منبع، مقصد و سیستم محلی) جلوگیری کنید و در هنگام استفاده از SFTP، به شما امکان می دهد از تمام روش های احراز هویت در هنگام دسترسی از راه دور استفاده کنید. میزبان ها، و نه فقط روش های غیر تعاملی. گزینه "-R" برای بازیابی رفتار قدیمی اضافه شده است.
- تنظیمات ForkAfterAuthentication به ssh مربوط به پرچم "-f" اضافه شد.
- تنظیم StdinNull را به ssh، مطابق با پرچم "-n" اضافه کرد.
- یک تنظیم SessionType به ssh اضافه شده است که از طریق آن می توانید حالت های مربوط به پرچم های "-N" (بدون جلسه) و "-s" (زیر سیستم) را تنظیم کنید.
- ssh-keygen به شما این امکان را می دهد که فاصله اعتبار کلید را در فایل های کلیدی مشخص کنید.
- پرچم "-Oprint-pubkey" به ssh-keygen اضافه شد تا کلید عمومی کامل را به عنوان بخشی از امضای sshsig چاپ کند.
- در ssh و sshd، هم کلاینت و هم سرور به استفاده از تجزیه‌کننده فایل پیکربندی محدودتر منتقل شده‌اند که از قوانین پوسته مانند برای مدیریت نقل قول‌ها، فاصله‌ها و کاراکترهای فرار استفاده می‌کند. تجزیه کننده جدید همچنین مفروضات قبلی را نادیده نمی گیرد، مانند حذف آرگومان ها در گزینه ها (به عنوان مثال، دستور DenyUsers دیگر نمی تواند خالی بماند)، نقل قول های بسته نشده، و مشخص کردن کاراکترهای چندگانه.
- هنگام استفاده از رکوردهای DNS SSHFP هنگام تأیید کلیدها، ssh اکنون همه رکوردهای منطبق را بررسی می کند، نه فقط آنهایی که حاوی نوع خاصی از امضای دیجیتال هستند.
- در ssh-keygen، هنگام تولید یک کلید FIDO با گزینه -Ochallenge، اکنون لایه داخلی برای هش کردن استفاده می شود، به جای libfido2، که امکان استفاده از دنباله های چالش بزرگتر یا کوچکتر از 32 بایت را فراهم می کند.
- در sshd، هنگام پردازش دستورالعمل های محیط="..." در فایل های authorized_keys، اولین تطابق اکنون پذیرفته می شود و محدودیت 1024 نام متغیر محیطی وجود دارد.
توسعه دهندگان OpenSSH همچنین در مورد تجزیه الگوریتم ها با استفاده از هش SHA-1 به دلیل افزایش کارایی حملات برخورد با یک پیشوند مشخص هشدار دادند (هزینه انتخاب یک برخورد تقریباً 50 هزار دلار برآورد شده است). در نسخه بعدی، ما قصد داریم به طور پیش فرض قابلیت استفاده از الگوریتم امضای دیجیتال کلید عمومی "ssh-rsa" را که در RFC اصلی برای پروتکل SSH ذکر شده بود، غیرفعال کنیم و همچنان در عمل به طور گسترده مورد استفاده قرار می گیرد.
برای آزمایش استفاده از 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 استفاده نشود. کلید باید تنها با یک نام وجود داشته باشد. گواهی کلید میزبان نباید استفاده شود. در known_hosts ماسک ها با نام میزبان نباید استفاده شوند. تنظیم VerifyHostKeyDNS باید غیرفعال باشد. پارامتر UserKnownHostsFile باید فعال باشد.
الگوریتم های توصیه شده برای مهاجرت عبارتند از 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).
منبع: opennet.ru