تاریخچه SSH از telnet تا OpenSSH و رمزنگاری پساکوانتومی

آغاز تاریخچه SSH

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

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

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

Telnet در RFC 854 تعریف شده است. این RFC را Jon Postel و Joyce Reynolds در May 1983 منتشر کردند. Telnet یک نشست ترمینال را توصیف می‌کند که روی TCP منتقل می‌شود و هیچ نوع رمزنگاری ندارد. هر بایتی که وارد می‌کنید، از جمله گذرواژه، به‌صورت بایت‌های ساده منتقل می‌شود و هر دستگاهی در مسیر می‌تواند آن را بخواند.

rlogin از Berkeley Unix پدید آمد و بعداً در RFC 1282 با عنوان BSD Rlogin، نوشتهٔ B. Kantor، در December 1991 مستند شد. این پروتکل چیزی بدتر از گذرواژهٔ قابل‌خواندن اضافه کرد: اعتماد مبتنی بر میزبان. می‌شد به یک سرور گفت ورود از یک میزبان نام‌برده را بدون هیچ گذرواژه‌ای بپذیرد. این RFC بخشی با عنوان «A Cautionary Tale» دارد که می‌گوید: «Bypassing password authentication from trusted hosts opens ALL the systems so configured when just one is compromised.» همچنین اشاره می‌کند که این اعتماد بر اساس hostnameها تعیین می‌شود؛ بنابراین compromise شدن DNS (domain name system) یا یک address جعلی می‌تواند آن را بی‌اثر کند.

هر دو طراحی با شبکه‌ای که در آن شکل گرفته بودند سازگار بودند. Ethernet اولیه یک رسانهٔ اشتراکی بود: هر دستگاه روی یک segment هر frame را دریافت می‌کرد و انتظار می‌رفت frameهایی را که برای آن آدرس‌دهی نشده‌اند نادیده بگیرد. دستگاهی که دیگر آن‌ها را نادیده نمی‌گرفت—و این همان معنای promiscuous mode است—ترافیک دیگران را می‌دید. اگر دانشگاهی را در نظر بگیریم که به هزاران دانشجو shell account می‌داد، یک account breach‌شده می‌توانست به password collector برای کل یک department تبدیل شود.

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

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

CERT به سایت‌ها توصیه کرد رمز عبور همه حساب‌هایی را که از طریق شبکه قابل دسترسی هستند تغییر دهند. اگر این توصیه را در چارچوب همان پروتکل‌ها بررسی کنید، مشکل آشکار است: رمز عبور جدید در نخستین استفاده، از همان مسیر و به‌صورت متن ساده عبور می‌کند. در telnet یا rlogin هیچ راهکاری برای اصلاح این مشکل وجود نداشت، زیرا هیچ‌یک از این دو پروتکل محلی برای قرار دادن چنین راهکاری نداشتند.

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

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

این نرم‌افزار بر پایهٔ دو تصمیم طراحی شکل گرفت. نشست رمزنگاری می‌شد؛ بنابراین شنونده‌ای در segment به اطلاعات مفیدی دست پیدا نمی‌کرد. همچنین سرور هویت خود را با یک key اثبات می‌کرد؛ بنابراین client می‌توانست تشخیص دهد که به ماشین درست متصل شده است. این همان رخنه‌ای بود که اعتماد rlogin به hostname بدون بررسی باقی گذاشته بود.

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

از یک release آزاد تا یک محصول تجاری

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

چرا OpenBSD در سال 1999 از OpenSSH fork کرد

در اوایل سال 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 بود که همراه با OpenBSD 2.6 در 1 December 1999 منتشر شد.

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

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

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

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

این نقص در خود پروتکل وجود داشت؛ بنابراین اصلاح آن بدون شکستن سازگاری ممکن نبود. در عوض، پیاده‌سازی‌ها یک detector ارائه کردند؛ یعنی کدی در فایلی با نام deattack.c که تلاش می‌کرد حمله را هنگام وقوع تشخیص دهد. در فوریه 2001 مشخص شد که خود detector نیز دچار سرریز عدد صحیح است؛ این نقص با شناسه CVE-2001-0144، امکان اجرای remote code را علیه سرورها و clientهایی فراهم می‌کرد که patch مربوطه را داشتند. طرحی که قابل تعمیر نباشد، patchهای بیشتری جمع می‌کند و هر patch نیز باگ‌های خودش را به همراه می‌آورد.

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

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

SSH-2 هیچ سازگاری wire با SSH-1 ندارد. به همین دلیل، شماره پروتکل تغییر کرد، نه صرفاً رقم اعشار آن.

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

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

نگه‌داشتن آن به‌عنوان یک گزینه برای تجهیزات قدیمی، انتخاب سازگارانه‌تری بود؛ اما detector مربوط به CRC-32 توضیح می‌دهد که چرا این انتخاب رد شد. دسترسی به سرریز فقط به این دلیل ممکن بود که کد پروتکل 1 در build قرار داشت و این کد در مسیری قرار گرفته بود که بیشتر مدیران تصور می‌کردند در سیستم‌هایشان غیرفعال است. کدی که release می‌شود، ممکن است مورد دسترسی قرار گیرد. کدی که حذف شده باشد، دیگر قابل دسترسی نیست.

چرا نخستین اتصال SSH دربارهٔ host key هشدار می‌دهد

رمزنگاری نشان می‌دهد که ترافیک خصوصی است. اما نشان نمی‌دهد طرف دیگر چه کسی است. اگر مهاجمی در مسیر قرار بگیرد و به‌جای سرور شما پاسخ دهد، یک نشست کاملاً رمزنگاری‌شده با مهاجم خواهید داشت؛ این وضعیت حملهٔ 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 را از کنسول provider یا build log سرور بخوانید. آن را به‌صورت یک رکورد SSHFP در DNS منتشر کنید (RFC 4255)؛ البته این کار فقط زمانی ارزش دارد که DNSSEC داشته باشید. راه دیگر، امضای host keyها با certificate authority (CA) خودتان است تا کلاینت‌ها به CA اعتماد کنند، نه به تک‌تک کلیدها. در عمل، بیشتر افراد بدون بررسی این درخواست را می‌پذیرند؛ بهتر است این واقعیت را صادقانه در نظر بگیریم.

کلیدهای عمومی چگونه گذرواژه‌ها را کنار زدند

احراز هویت با کلید عمومی از نخستین releaseهای SSH وجود داشت، اما سال‌ها طول کشید تا به روش معمول تبدیل شود. این سازوکار نامتقارن است: client با امضای یک challenge ثابت می‌کند که کلید خصوصی را در اختیار دارد و کلید خصوصی هرگز client را ترک نمی‌کند. گذرواژه برعکس عمل می‌کند. با وجود آن‌که SSH گذرواژه را داخل کانال رمزگذاری‌شده منتقل می‌کند، server secret واقعی را دریافت می‌کند. بنابراین یک server compromiseشده یا مخرب در نهایت چیزی در اختیار دارد که می‌تواند در جای دیگری علیه شما استفاده کند.

دلیل دوم به محاسبات مربوط است. هر server که پورت 22 آن روی یک آدرس عمومی باز باشد، شبانه‌روز login attemptهای خودکار دریافت می‌کند و گذرواژه رشته‌ای قابل حدس است. کلید از نظر عملی قابل حدس نیست. فعال‌کردن PasswordAuthentication no کل این دسته از حمله‌ها را متوقف می‌کند؛ به همین دلیل در هر hardening checklist دیده می‌شود. نحوه تولید و rotation کلیدها در مبانی مدیریت کلید SSH پوشش داده شده است و تنظیمات سمت server در سخت‌سازی SSH روی VPS آمده است.

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

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

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

DSA مسیر دیگری را طی کرد. OpenSSH 7.0 در سال 2015، ssh-dss host key و user key را هنگام اجرا غیرفعال کرد؛ زیرا این الگوریتم به private key با طول 160 بیت و به SHA-1 محدود است. Version 9.8 در تاریخ 1 July 2024، DSA را هنگام compile غیرفعال کرد. Version 10.0 در تاریخ 9 April 2025 آن را حذف کرد و طبق عبارت پروژه، «فرایند منسوخ‌کردن را که در سال 2015 آغاز شده بود تکمیل کرد». از غیرفعال‌شدن تا حذف کامل، 10 سال طول کشید.

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

همین فرایند اکنون برای key exchange نیز اجرا می‌شود؛ این بار پیش از آن‌که تهدید عملی شود. ترافیکی که امروز ضبط می‌شود، ممکن است سال‌ها بعد توسط کسی که زودتر به یک quantum computer توانمند دسترسی پیدا می‌کند ذخیره و رمزگشایی شود. بنابراین، key agreement باید پیش از ساخته‌شدن چنین ماشینی تغییر می‌کرد. OpenSSH 9.0 در تاریخ 8 April 2022، یک hybrid key exchange را به‌عنوان مقدار پیش‌فرض انتخاب کرد: sntrup761x25519-sha512@openssh.com یک الگوریتم post-quantum را با exchange مربوط به X25519 ترکیب می‌کند. بنابراین، اگر الگوریتم جدید عملکرد مورد انتظار را نداشته باشد، نتیجه از بخش کلاسیک ضعیف‌تر نخواهد بود. OpenSSH 9.9 در تاریخ 19 September 2024، mlkem768x25519-sha256 را اضافه کرد که بر پایه ML-KEM (module lattice key encapsulation mechanism) ساخته شده و NIST آن را در سال 2024 استاندارد کرده است. OpenSSH 10.0 آن را به مقدار پیش‌فرض برای key agreement تبدیل کرد و صفحه post-quantum پروژه منطق این تصمیم را توضیح می‌دهد. OpenSSH 10.1 در تاریخ 6 October 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 آن را کنترل می‌کند. مفهوم عملی این هشدار و اقدام لازم درباره serverی که آن را ایجاد می‌کند، در مقدارهای پیش‌فرض post-quantum برای key exchange در SSH توضیح داده شده است.

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

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

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

FAQ

چه کسی SSH را ایجاد کرد و چرا؟

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

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

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

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

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

چرا SSH در نخستین اتصال دربارهٔ host key سؤال می‌کند؟

چون client قبلاً آن سرور را ندیده است و چیزی ندارد که کلید آن را با آن مقایسه کند. رمزنگاری به‌تنهایی نمی‌تواند یک سرور معتبر را از ماشینی که در مسیر ارتباط قرار گرفته است تشخیص دهد؛ بنابراین SSH سرورها را با key شناسایی می‌کند و اطلاعات مشاهده‌شده را در ~/.ssh/known_hosts ثبت می‌کند. نخستین اتصال تنها زمانی است که هیچ مقدار ذخیره‌شده‌ای برای بررسی وجود ندارد؛ به همین دلیل client از شما سؤال می‌کند. fingerprint را با مقداری که از provider console یا خود سرور دریافت کرده‌اید مقایسه کنید و هر پیام REMOTE HOST IDENTIFICATION HAS CHANGED در اتصال‌های بعدی را تا زمانی که علت آن را توضیح نداده‌اید، یک رویداد واقعی در نظر بگیرید.

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

چون OpenSSH الگوریتم‌ها را طبق یک schedule منتشرشده کنار می‌گذارد. کلیدهای 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 در دسترس است، از هر دو مشکل جلوگیری می‌کند.