تاریخچه کامل SSH: از Telnet تا OpenSSH

تاریخچه SSH از کجا آغاز می‌شود

تاریخچه SSH با سرقت گذرواژه‌ها آغاز شد. پیش از سال 1995، ورود به یک ماشین یونیکس از راه دور به معنای استفاده از telnet یا rlogin بود و هر دوی این ابزارها گذرواژه شما را به‌صورت متن خوانا در شبکه ارسال می‌کردند. هر کسی که می‌توانست ترافیک شبکه را شنود کند، قادر به خواندن آن بود و تا اوایل دهه 1990، افراد دقیقاً همین کار را در مقیاس وسیع انجام می‌دادند.

SSH پاسخ یک فرد به این مشکل بود که در سال 1995 نوشته و به‌صورت رایگان عرضه شد. این پروتکل از آن زمان تاکنون یک‌بار بازنویسی شده است و برنامه‌ای که امروزه تقریباً همه از آن استفاده می‌کنند، انشعابی از یک انشعاب دیگر است. تاریخ‌های زیر اهمیت دارند، زیرا هر گام، واکنشی به یک شکست مشخص بوده است.

آنچه Telnet و rlogin در واقع ارسال می‌کردند

پروتکل Telnet در RFC 854 تعریف شده است که در مه 1983 توسط Jon Postel و Joyce Reynolds منتشر شد. این پروتکل یک نشست ترمینال را توصیف می‌کند که روی TCP منتقل می‌شود و فاقد هرگونه رمزنگاری است. هر بایتی که تایپ می‌کنید، از جمله رمز عبور شما، به صورت بایت‌های متن ساده (plain text) ارسال می‌شود که هر دستگاهی در مسیر می‌تواند آن را بخواند.

پروتکل rlogin از Berkeley Unix نشأت گرفت و بعداً در RFC 1282 (BSD Rlogin، نوشته B. Kantor، دسامبر 1991) مستند شد. این پروتکل چیزی بدتر از رمز عبور قابل خواندن را معرفی کرد: اعتماد مبتنی بر میزبان (host-based trust). به یک سرور می‌توان دستور داد که ورود از یک میزبان نام‌گذاری‌شده را بدون هیچ‌گونه رمز عبوری بپذیرد. این RFC بخشی با عنوان "یک داستان هشداردهنده" دارد که می‌گوید: «دور زدن احراز هویت رمز عبور از میزبان‌های مورد اعتماد، تمام سیستم‌هایی را که به این شکل پیکربندی شده‌اند، در صورت نفوذ به تنها یکی از آن‌ها، در معرض خطر قرار می‌دهد.» همچنین اشاره می‌کند که این اعتماد بر اساس نام میزبان‌ها است، بنابراین نفوذ به DNS (سامانه نام دامنه) یا جعل آدرس، این مکانیزم را بی‌اثر می‌کند.

هر دو طراحی با شبکه‌ای که در آن متولد شدند، سازگار بودند. اترنت اولیه یک رسانه اشتراکی بود: هر دستگاه در یک بخش، تمام فریم‌ها را دریافت می‌کرد و انتظار می‌رفت فریم‌هایی را که خطاب به او نبودند، نادیده بگیرد. دستگاهی که از نادیده گرفتن آن‌ها دست می‌کشید (که معنای حالت promiscuous است)، ترافیک سایرین را مشاهده می‌کرد. اگر دانشگاهی را در نظر بگیرید که به هزاران دانشجو حساب shell می‌دهد، یک حساب کاربریِ نفوذشده به جمع‌آوری‌کننده رمز عبور برای کل یک دانشکده تبدیل می‌شد.

اخطاریه سال 1994 که بدون اصلاحیه منتشر شد

در تاریخ 3 فوریه 1994، مرکز CERT اخطاریه CA-94:01 را با عنوان "حملات نظارت مداوم بر شبکه" منتشر کرد. این گزارش حاکی از آن بود که مهاجمان اطلاعات دسترسی ده‌ها هزار سیستم در سراسر اینترنت را سرقت کرده‌اند. ابزاری که آن‌ها استفاده می‌کردند، رابط شبکه را در حالت promiscuous قرار می‌داد و ابتدای هر نشست جدید telnet، rlogin و FTP را ضبط می‌کرد؛ بخشی که حاوی نام کاربری و رمز عبور است.

مرکز CERT به سایت‌ها توصیه کرد که رمز عبور تمام حساب‌های دارای دسترسی شبکه را تغییر دهند. این توصیه را در کنار پروتکل‌های موجود بررسی کنید تا متوجه دام شوید: رمز عبور جدید در اولین استفاده، از همان مسیر شبکه به صورت متن ساده (clear text) عبور می‌کند. هیچ اصلاحیه‌ای در telnet یا rlogin وجود نداشت، زیرا هیچ‌کدام از این پروتکل‌ها فضایی برای گنجاندن مکانیزم امنیتی نداشتند.

چرا یک حمله شنود در هلسینکی منجر به تولید SSH شد

در سال 1995، شبکه دانشگاه صنعتی هلسینکی هدف یک حمله شنود رمز عبور از نوعی که CERT توصیف کرده بود، قرار گرفت. تاتو یلونن، یکی از محققان آنجا، جایگزینی برای آن نوشت و در ژوئیه 1995 آن را به عنوان نرم‌افزار رایگان منتشر کرد. او نام آن را Secure Shell گذاشت.

دو تصمیم طراحی باعث موفقیت آن شد. نشست (session) رمزنگاری می‌شد، بنابراین شنودکننده در آن بخش از شبکه چیزی مفید دریافت نمی‌کرد. همچنین سرور هویت خود را با یک کلید اثبات می‌کرد، بنابراین کلاینت می‌توانست تشخیص دهد که آیا به ماشین درستی متصل شده است یا خیر؛ این همان حفره‌ای بود که اعتماد به hostname در rlogin باز گذاشته بود.

این ابزار همچنین به این دلیل گسترش یافت که دستورات آن با دستوراتی که کاربران از قبل تایپ می‌کردند مطابقت داشت. ssh جایگزین rsh و rlogin شد و scp جایگزین rcp گردید. هزینه تغییر، فقط تغییر عادت بود، نه تغییر گردش کار. تا پایان سال 1995، پایگاه کاربران به حدود 20,000 نفر در پنجاه کشور رسیده بود. در دسامبر همان سال، یلونن شرکت SSH Communications Security را برای توسعه و فروش این نرم‌افزار تأسیس کرد.

از یک نسخهٔ رایگان به یک محصول تجاری

با تبدیل شدن SSH به یک کسب‌وکار، مجوز استفاده از سورس‌کد تغییر کرد. نسخه‌های بعدی شامل شرایطی بودند که فعالیت‌های دیگران با این کد را محدود می‌کرد و آخرین نسخه‌ای که هر کسی می‌توانست آزادانه از آن استفاده مجدد کند، ssh 1.2.12 بود. هیچ‌کدام از این موارد غیرقانونی نیست. این موضوع صرفاً به این معنا بود که نسخهٔ SSH که سایر نقاط جهان می‌توانستند بر پایهٔ آن توسعه دهند، متوقف شد، در حالی که توسعهٔ آن در جایی دیگر ادامه یافت که برای عموم قابل دسترسی نبود. مجوزها تعیین می‌کنند که کدام کد باقی می‌ماند؛ الگویی که مطالعه دربارهٔ آن در چگونه مجوزهای متن‌باز زیرساخت‌های مدرن را شکل دادند ارزشمند است.

چرا OpenBSD در سال 1999 اقدام به fork کردن OpenSSH کرد

در اوایل سال 1999، Björn Grönvall به سراغ آخرین نسخهٔ آزاد رفت و شروع به رفع باگ‌های آن کرد. نسخهٔ او OSSH نام داشت و تنها از پروتکل SSH 1.3 پشتیبانی می‌کرد.

پروژهٔ OpenBSD، نسخهٔ OSSH را دریافت و بازسازی کرد. طبق روایت خود پروژه، Theo de Raadt، Niels Provos، Markus Friedl، Bob Beck، Aaron Campbell و Dug Song کار پاک‌سازی، بازبینی و توسعهٔ کد را انجام دادند. نتیجهٔ این تلاش، OpenSSH 1.2.2 بود که در تاریخ 1 دسامبر 1999 همراه با OpenBSD 2.6 عرضه شد.

چرا یک fork توسط یک پروژهٔ کوچک سیستم‌عامل، سرانجام روی تقریباً تمام ماشین‌ها قرار گرفت؟ به دلیل نیازی که OpenBSD به آن داشت. OpenBSD یک سیستم پایهٔ بازبینی‌شده ارائه می‌دهد که قرار است در پیکربندی پیش‌فرض خود امن باشد؛ بنابراین ورود از راه دورِ رمزنگاری‌شده باید در آن سیستم پایه قرار می‌گرفت، آن هم تحت مجوزی که هیچ محدودیتی نداشته باشد. کد بازبینی‌شده تحت یک مجوز بدون محدودیت، دقیقاً همان چیزی بود که سایر فروشندگان سیستم‌عامل نیز به آن نیاز داشتند. Damien Miller، Philip Hands و دیگران تقریباً بلافاصله یک شاخهٔ قابل‌حمل (portable) ایجاد کردند که p در نسخه‌هایی مانند 10.5p1 از همان‌جا نشأت می‌گیرد. OpenBSD نسخهٔ تمیز را توسعه می‌دهد و شاخهٔ قابل‌حمل، کدهای رابط (glue) لازم برای سایر سیستم‌ها را به آن می‌افزاید. نحوهٔ تقسیم یونیکس به سیستم‌هایی که امروز اجرا می‌کنیم دلیل اصلی نیاز به این کدهای رابط است.

پشتیبانی از نسخهٔ دوم پروتکل در ادامه اضافه شد. OpenSSH 2.0 در تاریخ 15 ژوئن 2000 همراه با OpenBSD 2.7 عرضه شد.

چرا SSH-2 یک پروتکل جدید است و نه صرفاً یک ارتقای نسخه

پروتکل SSH-1 یکپارچگی جریان رمزنگاری‌شده را با استفاده از CRC-32 محافظت می‌کرد؛ یک checksum که برای شناسایی خطاهای انتقال طراحی شده بود، نه برای مقابله با مهاجمان. در سال 1998، Ariel Futoransky و Emiliano Kargieman از شرکت CORE SDI نشان دادند که این موضوع چه هزینه‌ای دارد. با استفاده از حالت‌های رمزنگاری CBC یا CFB و بررسی CRC-32، مهاجمی که تنها 16 بایت از متن اصلی (plaintext) را بداند، می‌تواند ciphertext دلخواه خود را تزریق کند که گیرنده آن را معتبر می‌پندارد؛ این یعنی اجرای دستورات روی سرور.

این نقص در ذات پروتکل بود، بنابراین بدون شکستن سازگاری (compatibility) قابل اصلاح نبود. پیاده‌سازی‌ها به جای آن، یک آشکارساز (detector) ارائه کردند؛ کدی در فایلی به نام deattack.c که تلاش می‌کرد حمله را در لحظه وقوع شناسایی کند. در فوریه 2001 مشخص شد که خودِ این آشکارساز دارای یک سرریز عدد صحیح (integer overflow) با شناسه CVE-2001-0144 است که امکان اجرای کد از راه دور را روی سرورها و کلاینت‌هایی که پچ را دریافت کرده بودند، فراهم می‌کرد. طراحی‌ای که قابل تعمیر نباشد، پچ‌ها را جمع‌آوری می‌کند و پچ‌ها نیز باگ‌های خاص خود را به همراه می‌آورند.

پروتکل SSH-2 در یک کارگروه IETF به نام secsh تدوین شد و در ژانویه 2006 در قالب RFCها منتشر گردید: معماری در RFC 4251، لایه انتقال در RFC 4253، احراز هویت کاربر در RFC 4252 و لایه اتصال در RFC 4254. تقسیم‌بندی به لایه‌ها بخش مهم ماجراست، زیرا هر لایه می‌تواند به‌طور مستقل جایگزین شود. بخش عمده‌ای از تاریخچه بعدی این پروتکل، همین فرآیند جایگزینی است.

دو تغییر برجسته وجود دارد. یکپارچگی از CRC-32 به HMAC (کد احراز هویت پیام مبتنی بر هش) تغییر یافت که با یک secret مشترک کلیدگذاری می‌شود؛ بنابراین مهاجمی که نتواند MAC را محاسبه کند، قادر به جعل بسته نخواهد بود. همچنین توافق کلید (key agreement) به Diffie-Hellman منتقل شد. در SSH-1، کلاینت کلید نشست (session key) را انتخاب می‌کرد و آن را با کلیدهای RSA سرور رمزنگاری می‌کرد؛ بنابراین هر کسی که بعداً به آن کلیدهای خصوصی دست می‌یافت، می‌توانست نشست‌های ضبط‌شده را رمزگشایی کند. Diffie-Hellman برای هر نشست یک secret جدید تولید می‌کند که هرگز منتقل نمی‌شود؛ بنابراین ضبط ترافیک در حال حاضر و سرقت کلید میزبان در آینده، هیچ نتیجه‌ای برای مهاجم نخواهد داشت. این ویژگی «محرمانگی پیشرو» (forward secrecy) نامیده می‌شود.

پروتکل SSH-2 هیچ سازگاری در سطح شبکه با SSH-1 ندارد. به همین دلیل است که عدد نسخه تغییر کرد و نه رقم اعشاری آن.

چرا SSH-1 به‌جای اصلاح، حذف شد

حذف این پروتکل طی سه OpenSSH releases انجام شد. نسخه 7.0 در تاریخ 11 August 2015، پروتکل 1 را به‌صورت پیش‌فرض در زمان کامپایل غیرفعال کرد. نسخه 7.4 در تاریخ 19 December 2016، پشتیبانی سمت سرور را برای آن حذف کرد. نسخه 7.6 در تاریخ 3 October 2017، سمت کلاینت را نیز به همراه گزینه‌های پیکربندی و مستندات مربوطه پاک کرد.

نگهداری آن به‌عنوان یک گزینه برای تجهیزات قدیمی، انتخاب دوستانه‌تری به نظر می‌رسید، اما وجود detector برای CRC-32 توضیح می‌دهد که چرا این انتخاب رد شد. سرریز (overflow) تنها به این دلیل قابل دسترسی بود که کد پروتکل 1 کامپایل شده بود و در مسیری قرار داشت که اکثر مدیران سیستم تصور می‌کردند غیرفعال است. کدی که در نرم‌افزار عرضه می‌شود (ships)، قابل دسترسی است. کدی که حذف شده باشد، غیرقابل دسترسی است.

چرا اولین اتصال SSH شما درباره کلید میزبان هشدار می‌دهد

رمزنگاری به شما می‌گوید که ترافیک خصوصی است، اما هویت طرف مقابل را تأیید نمی‌کند. اگر یک مهاجم در مسیر قرار بگیرد و به‌جای سرور شما پاسخ دهد، شما یک نشست کاملاً رمزنگاری‌شده با مهاجم خواهید داشت که به آن حمله machine-in-the-middle می‌گویند. SSH با استفاده از کلید میزبان (host key) به این مسئله پاسخ می‌دهد: سرور ثابت می‌کند که نیمه خصوصی یک جفت‌کلید را در اختیار دارد و کلاینت آن کلید را با مقداری که دفعه قبل ثبت کرده است، مقایسه می‌کند. اگر به جزئیات فنی خودِ اتصال نیاز دارید، آنچه هنگام باز کردن اتصال SSH رخ می‌دهد را ببینید.

در اولین اتصال، سابقه قبلی وجود ندارد؛ بنابراین کلاینت چیزی برای مقایسه ندارد و ناچار است از شما بپرسد:

The authenticity of host 'vps.example.com (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:BQ0Qs2jVXhH2lPZ2rM0aQ0mQ8f9pQ0m3nH0oQ1bYqkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

پاسخ مثبت (yes) باعث ذخیره آن کلید در ~/.ssh/known_hosts می‌شود. هر اتصال بعدی با مقدار ذخیره‌شده مقایسه می‌شود و در صورت عدم تطابق، برنامه شدیدترین هشدار ممکن را نمایش می‌دهد:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

تفسیر صادقانه آن پرسش اولیه این است که پروتکل به تنها نقطه ضعف خود اعتراف می‌کند. اعتماد در اولین استفاده (Trust on first use) به این معناست که امنیت اولین اتصال، تنها به اندازه امنیت شبکه‌ای است که در آن هستید. شما می‌توانید این شکاف را ببندید. پیش از اتصال، اثر انگشت (fingerprint) را از کنسول ارائه‌دهنده یا لاگ ساخت سرور بخوانید. آن را به‌عنوان یک رکورد SSHFP در DNS منتشر کنید (RFC 4255) که البته تنها در صورت داشتن DNSSEC ارزش انجام دارد. یا کلیدهای میزبان را با مرجع گواهی (CA) خود امضا کنید تا کلاینت‌ها به CA اعتماد کنند، نه به تک‌تک کلیدها. در عمل، اکثر افراد بدون بررسی، پرسش را تأیید می‌کنند که بهتر است در این مورد صادق باشیم.

چگونه کلیدهای عمومی جایگزین رمزهای عبور شدند

احراز هویت با کلید عمومی از همان نسخه‌های اولیه SSH وجود داشت، اما سال‌ها طول کشید تا به یک عادت معمول تبدیل شود. این مکانیزم نامتقارن است: کلاینت با امضای یک چالش ثابت می‌کند که کلید خصوصی را در اختیار دارد و کلید خصوصی هرگز کلاینت را ترک نمی‌کند. رمز عبور دقیقاً برعکس عمل می‌کند. با وجود اینکه SSH رمز عبور را درون کانال رمزگذاری‌شده حمل می‌کند، سرور در نهایت راز اصلی را دریافت می‌کند؛ بنابراین یک سرور نفوذپذیر یا مخرب، چیزی را در اختیار می‌گیرد که می‌تواند از آن علیه شما در جای دیگری استفاده کند.

دلیل دوم، محاسبات است. هر سروری که پورت 22 آن روی یک آدرس عمومی باز باشد، شبانه‌روز درخواست‌های خودکار برای ورود دریافت می‌کند و password یک رشتهٔ قابل حدس است. key از نظر عملی قابل حدس نیست. تنظیم PasswordAuthentication no کل این دسته از حملات را متوقف می‌کند؛ به همین دلیل در هر فهرست hardening دیده می‌شود. این کار fallbackای را هم حذف می‌کند که پیش‌تر هنگام خراب‌شدن key به کمک شما می‌آمد. بنابراین، پیش از آن‌که خودتان پشت در بمانید، یاد بگیرید چگونه چند خطای متفاوتی را که همگی پیام Permission denied (publickey) گزارش می‌کنند از یکدیگر تشخیص دهید. نداشتن password همچنین به انباشته‌شدن keyها منجر می‌شود. agent که ده‌ها key در اختیار دارد، هرکدام را به‌ترتیب ارائه می‌کند تا سرور به حد تلاش‌های مجاز برسد و اتصال را قطع کند؛ به همین دلیل است که ورود ممکن است حتی با بارگذاری key درست، با پیام Too many authentication failures شکست بخورد. ایجاد و چرخش keyها در مبانی مدیریت SSH key پوشش داده شده است و تنظیمات سمت سرور در hardening کردن SSH روی VPS توضیح داده شده است.

چرا لیست الگوریتم‌های SSH دائماً تغییر می‌کند

یک پروتکل لایه‌بندی‌شده اجازه می‌دهد الگوریتم‌ها بدون نیاز به پروتکل جدید، بازنشسته شوند. OpenSSH به‌طور پیوسته از این آزادی استفاده کرده است و تاریخ‌های انتشار، سرعت این روند را نشان می‌دهند.

الگوریتم Ed25519 در تاریخ 30 ژانویه 2014 در OpenSSH 6.5، در کنار رمزنگار chacha20-poly1305 و فرمت کلید خصوصی محافظت‌شده با bcrypt معرفی شد. امضاهای Ed25519 مقدار nonce هر امضا را به‌صورت قطعی (deterministic) مشتق می‌کنند؛ بنابراین یک مولد اعداد تصادفی ضعیف در زمان امضا نمی‌تواند باعث نشت کلید خصوصی شود. این دقیقاً همان روشی است که کلیدهای خصوصی DSA و ECDSA در حوادث واقعی بازیابی شده‌اند.

DSA مسیر متفاوتی را طی کرد. OpenSSH 7.0 در سال 2015 استفاده از کلیدهای میزبان و کاربر ssh-dss را در زمان اجرا غیرفعال کرد، زیرا این الگوریتم به کلید خصوصی 160 بیتی و SHA-1 محدود است. نسخه 9.8 در تاریخ 1 جولای 2024، DSA را در زمان کامپایل غیرفعال کرد. نسخه 10.0 در تاریخ 9 آوریل 2025 آن را حذف کرد که به گفته تیم پروژه، «تکمیل فرایند منسوخ‌سازی است که از سال 2015 آغاز شده بود». ده سال از غیرفعال‌سازی تا حذف کامل طول کشید.

RSA ناپدید نشد، اما فرمت امضای قدیمی آن کنار رفت. OpenSSH 8.8 در تاریخ 26 سپتامبر 2021، پذیرش امضاهای RSA ساخته‌شده با SHA-1 را به‌صورت پیش‌فرض متوقف کرد. یادداشت‌های انتشار دلیل آن را به‌وضوح بیان می‌کنند: SHA-1 از نظر رمزنگاری شکسته شده است و برخوردهای chosen-prefix با هزینه‌ای کمتر از 50,000 دلار آمریکا قابل دستیابی بودند. اگر هنگام اتصال به یک سرور قدیمی با sign_and_send_pubkey: no mutual signature supported مواجه شده‌اید، این همان تغییر است. کلید شما مشکلی ندارد؛ الگوریتم امضایی که سمت مقابل درخواست کرده، مورد تأیید نیست.

همین فرایند اکنون برای تبادل کلید در جریان است، این بار پیش از آنکه تهدیدی جدی شود. ترافیک ضبط‌شده امروز می‌تواند ذخیره شده و سال‌ها بعد توسط کسی که به یک کامپیوتر کوانتومی قدرتمند دسترسی دارد، رمزگشایی شود؛ بنابراین توافق کلید باید پیش از وجود چنین ماشینی تغییر می‌کرد. OpenSSH 9.0 در تاریخ 8 آوریل 2022، تبادل کلید ترکیبی را به پیش‌فرض تبدیل کرد: sntrup761x25519-sha512@openssh.com یک الگوریتم پساکوانتومی را با تبادل X25519 جفت می‌کند تا نتیجه در صورت ضعف الگوریتم جدید، ضعیف‌تر از بخش کلاسیک نباشد. OpenSSH 9.9 در تاریخ 19 سپتامبر 2024، mlkem768x25519-sha256 را اضافه کرد که بر پایه ML-KEM (مکانیسم کپسوله‌سازی کلید مبتنی بر شبکه پیمانه‌ای) ساخته شده و در سال 2024 توسط NIST استاندارد شده است. OpenSSH 10.0 آن را به پیش‌فرض برای توافق کلید تبدیل کرد و صفحه پساکوانتومی پروژه دلایل آن را توضیح می‌دهد. OpenSSH 10.1 در تاریخ 6 اکتبر 2025، شروع به نمایش هشدار در مواردی کرد که سمت مقابل قادر به انجام این کار نیست:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded.

این هشدار به‌طور پیش‌فرض فعال است و گزینهٔ WarnWeakCrypto در ssh_config آن را کنترل می‌کند. معنای عملی این هشدار و اقدام لازم دربارهٔ سروری که آن را ایجاد می‌کند، در پیش‌فرض‌های تبادل کلید SSH پساکوانتومی توضیح داده شده است. خود هشدار به سرور اشاره می‌کند، اما یک خط KexAlgorithms در پیکربندی client خودتان نیز می‌تواند گزینه‌های پساکوانتومی را به همان اندازه غیرفعال کند؛ بنابراین پیش از ارتقای هر چیزی، بررسی کنید اتصال شما واقعاً از کدام تبادل کلید استفاده کرده است.

این تاریخچه برای سروری که پیش رو دارید چه معنایی دارد

دستوری که تایپ می‌کنید از سال 1995 تاکنون تغییر چندانی نکرده است. تقریباً تمام اجزای زیرساختی آن جایگزین شده‌اند: بررسی یکپارچگی، تبادل کلید، الگوریتم‌های امضا و خودِ پایگاه کد. این امر تنها به این دلیل ممکن شد که هر جایگزینی با یک حذفِ آگاهانه به پایان رسید و هر حذف، برای شخصی مشکلی ایجاد کرد.

بنابراین، امنیت SSH شما عمدتاً توسط نسخه‌ای که استفاده می‌کنید تعیین می‌شود. تنظیمات پیش‌فرض، تصمیمات مربوط به اینکه کدام الگوریتم‌ها ارائه شوند، کدام‌ها رد شوند و چه هشدارهایی را مشاهده کنید، در بر می‌گیرند. یک سرور قدیمی همچنان هر آنچه را که در زمان انتشارش مجاز بوده ارائه می‌دهد و برای سازگاری با یک کلاینت قدیمی، سطح امنیت خود را پایین می‌آورد. تا اوت 2026، نسخه فعلی OpenSSH 10.5 است که در 11 اوت 2026 منتشر شده است. فاصله بین این نسخه و نسخه‌ای که روی ماشینی قرار دارد که سه سال است کسی به آن دست نزده، ابعاد مشکل را نشان می‌دهد. بررسی این موضوع بخشی از ده دقیقه اول کار با یک VPS جدید است.

FAQ

چه کسی SSH را ساخت و چرا؟

تاتو یلونن (Tatu Ylönen)، پژوهشگر دانشگاه صنعتی هلسینکی، SSH را در سال 1995 و پس از یک حملهٔ شنود رمز عبور در شبکهٔ دانشگاه نوشت. ابزارهای ورود از راه دور آن زمان، یعنی telnet و rlogin، رمزهای عبور را به‌صورت متن خوانا در شبکه ارسال می‌کردند؛ بنابراین هر کسی که یک بخش مشترک از شبکه را مانیتور می‌کرد، می‌توانست اعتبارنامه‌ها را هنگام عبور جمع‌آوری کند. او این برنامه را در ژوئیه 1995 به‌عنوان نرم‌افزار رایگان منتشر کرد. تا پایان همان سال، این ابزار حدود 20,000 کاربر در پنجاه کشور داشت و او در دسامبر 1995 شرکت SSH Communications Security را تأسیس کرد.

تفاوت SSH-1 و SSH-2 چیست؟

این‌ها دو پروتکل متفاوت هستند که با یکدیگر سازگاری ندارند. SSH-1 یک پروتکل یکپارچه بود که از CRC-32 برای یکپارچگی داده استفاده می‌کرد و کلاینت در آن، یک کلید نشست (session key) را که با کلیدهای RSA سرور رمزنگاری شده بود، ارسال می‌کرد. SSH-2 وظایف را به لایهٔ انتقال، لایهٔ احراز هویت و لایهٔ اتصال تقسیم می‌کند (RFCهای 4251 تا 4254، ژانویه 2006)، از HMAC برای یکپارچگی استفاده می‌کند و کلیدهای نشست را با Diffie-Hellman مشتق می‌کند؛ بنابراین حتی اگر کلید میزبان (host key) بعداً سرقت شود، ترافیک ضبط‌شده همچنان محرمانه باقی می‌ماند. SSH-1 طی چند مرحله از OpenSSH حذف شد و در نهایت با نسخه 7.6 در اکتبر 2017 به پایان رسید.

چرا OpenSSH جایگزین پیاده‌سازی اصلی SSH شد؟

توسعهٔ نسخهٔ اصلی به یک محصول تجاری با مجوز محدودکننده تبدیل شد و آخرین نسخهٔ قابل استفادهٔ آزاد، ssh 1.2.12 بود. در اوایل سال 1999، بیورن گرونوال (Björn Grönvall) آن نسخه را با نام OSSH احیا کرد و تیم OpenBSD، پروژهٔ OSSH را به OpenSSH فورک کرد که همراه با OpenBSD 2.6 در 1 دسامبر 1999 عرضه شد. OpenBSD به کدی بازبینی‌شده تحت یک مجوز بدون محدودیت برای سیستم پایهٔ خود نیاز داشت و همین دو ویژگی باعث شد که سایر سیستم‌عامل‌ها نیز بتوانند همان پیاده‌سازی را از طریق شاخهٔ portable عرضه کنند.

چرا SSH در اولین اتصال دربارهٔ کلید میزبان سؤال می‌پرسد؟

زیرا کلاینت قبلاً آن سرور را ندیده است و چیزی برای مقایسهٔ کلید آن ندارد. رمزنگاری به‌تنهایی نمی‌تواند یک سرور صادق را از ماشینی که در میانهٔ مسیر قرار گرفته (man-in-the-middle) تشخیص دهد؛ بنابراین SSH سرورها را با کلید شناسایی می‌کند و آنچه را دیده است در ~/.ssh/known_hosts ثبت می‌کند. اولین اتصال تنها لحظه‌ای است که هیچ مقدار ذخیره‌شده‌ای برای بررسی وجود ندارد و به همین دلیل کلاینت از شما سؤال می‌پرسد. اثر انگشت (fingerprint) را با موردی که از کنسول ارائه‌دهنده یا خود سرور دریافت کرده‌اید مقایسه کنید و هر پیام بعدی با عنوان REMOTE HOST IDENTIFICATION HAS CHANGED را تا زمانی که دلیل آن را نیافته‌اید، یک رویداد واقعی تلقی کنید.

چرا کلیدهای قدیمی SSH پس از ارتقا از کار می‌افتند؟

زیرا OpenSSH الگوریتم‌ها را طبق یک زمان‌بندی اعلام‌شده بازنشسته می‌کند. کلیدهای DSA (ssh-dss) به‌طور پیش‌فرض در OpenSSH 7.0 در سال 2015 غیرفعال و در OpenSSH 10.0 در تاریخ 9 آوریل 2025 به‌طور کامل حذف شدند. کلیدهای RSA همچنان کار می‌کنند، اما امضاهای ساخته‌شده با SHA-1 به‌طور پیش‌فرض در OpenSSH 8.8 در سپتامبر 2021 غیرفعال شدند که هنگام اتصال به یک سرور قدیمی به‌صورت sign_and_send_pubkey: no mutual signature supported ظاهر می‌شود. یک کلید Ed25519 که از زمان OpenSSH 6.5 در ژانویه 2014 در دسترس است، از هر دو مشکل جلوگیری می‌کند.