تاريخ SSH من Telnet إلى OpenSSH وما بعده

بدايات تاريخ SSH

يبدأ تاريخ SSH بكلمات مرور مسروقة. قبل 1995، كان تسجيل الدخول إلى جهاز Unix بعيد يعني استخدام telnet أو rlogin، وكان كلاهما يرسل كلمة المرور عبر الشبكة كنص مقروء. كان بإمكان أي شخص يراقب حركة الشبكة قراءتها، وبحلول أوائل تسعينيات القرن الماضي كان الناس يفعلون ذلك على نطاق واسع.

كان SSH إجابة شخص واحد عن هذه المشكلة. كُتب في 1995 وأُتيح مجاناً. أُعيد بناء البروتوكول مرة واحدة منذ ذلك الحين، والبرنامج الذي يشغّله معظم الناس اليوم هو fork لمشروع fork آخر. التواريخ أدناه مهمة، لأن كل خطوة منها كانت استجابة لفشل محدد.

ما الذي أرسله telnet وrlogin فعلياً

يُعرَّف Telnet في RFC 854، الذي نشره Jon Postel وJoyce Reynolds في May 1983. ويصف جلسة طرفية تُنقل عبر 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." كما يذكر أن الثقة تعتمد على أسماء المضيفين، ولذلك يمكن لإ اختراق DNS (domain name system) أو عنوان مُنتحل تجاوزها.

كان كلا التصميمين مناسباً للشبكة التي نشآ فيها. كانت Ethernet في بداياتها وسيطاً مشتركاً: كل جهاز على مقطع الشبكة يستقبل كل إطار، وكان يُتوقع منه تجاهل الإطارات غير الموجّهة إليه. أما الجهاز الذي يتوقف عن تجاهلها، وهو ما يعنيه promiscuous mode، فيرى حركة الشبكة الخاصة بالجميع. أضف إلى ذلك جامعة تمنح حسابات shell لآلاف الطلاب، فيتحول حساب واحد مخترق إلى أداة لجمع كلمات المرور من قسم كامل.

الإشعار الأمني الصادر عام 1994 من دون إصلاح

في 3 February 1994، نشر CERT الإشعار CA-94:01 بعنوان "Ongoing Network Monitoring Attacks". أفاد الإشعار بأن متسللين التقطوا معلومات الوصول إلى عشرات الآلاف من الأنظمة عبر الإنترنت. كانت الأداة المستخدمة تضع واجهة الشبكة في وضع promiscuous، وتسجّل بداية كل جلسة جديدة عبر telnet وrlogin وFTP، وهي الجزء الذي يحمل اسم المستخدم وكلمة المرور.

أوصى CERT المواقع بتغيير كلمة المرور لكل حساب يمكن الوصول إليه عبر الشبكة. عند مقارنة ذلك بالبروتوكولات، تتضح المشكلة: تعبر كلمة المرور الجديدة السلك نفسه بنص واضح عند استخدامها للمرة الأولى. لم يكن هناك إصلاح يمكن إدخاله في telnet أو rlogin، لأن أياً من البروتوكولين لم يكن يوفّر موضعاً لوضعه.

لماذا أدّى هجوم تنصّت في هلسنكي إلى ظهور SSH

في عام 1995، تعرّضت شبكة جامعة هلسنكي للتكنولوجيا لهجوم لالتقاط كلمات المرور من النوع الذي وصفه CERT. كتب Tatu Ylönen، وهو باحث في الجامعة، بديلاً وأصدره كبرنامج مجاني في يوليو 1995. وأطلق عليه اسم Secure Shell.

اعتمد البرنامج على قرارين تصميميين. كانت الجلسة مشفّرة، لذلك لم يتعلم المتنصّت على مقطع الشبكة أي معلومات مفيدة. كما أثبت الخادم هويته باستخدام مفتاح تشفيري، ولذلك كان بإمكان العميل معرفة ما إذا كان قد اتصل بالجهاز الصحيح. وهذه هي الثغرة التي تركتها آلية الثقة باسم المضيف في rlogin مفتوحة.

وانتشر البرنامج أيضاً لأن أوامره تطابقت مع الأوامر التي كان المستخدمون يكتبونها بالفعل. كان ssh بديلاً عن rsh وrlogin، وكان scp بديلاً عن rcp. تطلّب الانتقال تغيير عادة، لا تغييراً في سير العمل. وبحلول نهاية عام 1995، بلغ عدد المستخدمين نحو 20,000 مستخدم في خمسين دولة. وفي ديسمبر من ذلك العام، أسّس Ylönen شركة SSH Communications Security لتطوير البرنامج وبيعه.

من إصدار حر إلى منتج تجاري

مع تحوّل SSH إلى نشاط تجاري، تغيّر الترخيص المطبَّق على الشيفرة المصدرية. حملت الإصدارات اللاحقة شروطاً قيّدت ما يمكن للآخرين فعله بهذه الشيفرة، وكان آخر إصدار يمكن لأي شخص إعادة استخدامه بحرية هو ssh 1.2.12. لا يوجد في ذلك ما هو غير سليم. كان معنى ذلك ببساطة أن إصدار SSH الذي يستطيع بقية العالم البناء عليه توقف عن التطور، بينما استمر التطوير في مكان لم يعد ذلك العالم قادراً على متابعته. تحدد التراخيص أي شيفرة تستمر، وهو نمط يستحق القراءة عنه في كيف شكّل ترخيص المصادر المفتوحة البنية التحتية الحديثة.

سبب تفرّع OpenBSD عن OpenSSH في 1999

في أوائل عام 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.

لماذا انتهى تفرّع أنشأه مشروع نظام تشغيل صغير إلى الوجود على كل جهاز تقريباً؟ لأن ذلك التفرّع لبّى احتياجات OpenBSD. يطرح OpenBSD نظاماً أساسياً خضع للتدقيق، ومصمماً ليكون آمناً في إعداداته الافتراضية. لذلك كان يجب أن يكون تسجيل الدخول البعيد المشفّر جزءاً من ذلك النظام الأساسي، وبترخيص لا يفرض أي قيود. وكانت الشيفرة المدققة ذات الترخيص غير المقيّد هي بالضبط ما أراده كل مورّد آخر لأنظمة التشغيل أيضاً. بدأ Damien Miller وPhilip Hands وآخرون فرعاً محمولاً على الفور تقريباً، ومن هنا يأتي p في إصدار مثل 10.5p1. يطوّر OpenBSD النسخة النظيفة، بينما يضيف الفرع المحمول طبقة الربط اللازمة لكل ما عدا ذلك. طريقة انقسام 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 يختاره، ويقبله الطرف المستقبل على أنه أصلي. وهذا يعني تنفيذ أوامر على الخادم.

كان الخلل موجوداً في البروتوكول، لذلك لم يكن من الممكن تصحيحه من دون كسر التوافق. وبدلاً من ذلك، أضافت التطبيقات كاشفاً في ملف اسمه deattack.c، يحاول التعرّف على الهجوم أثناء حدوثه. في فبراير 2001، تبيّن أن الكاشف نفسه يحتوي على integer overflow، وهو CVE-2001-0144، ما أتاح تنفيذ تعليمات برمجية عن بُعد ضد الخوادم والعملاء الذين يطبقون التصحيح. التصميم الذي لا يمكن إصلاحه يتراكم عليه التصحيحات، وتحمل هذه التصحيحات أخطاءها الخاصة.

طُوّر SSH-2 ضمن مجموعة عمل في IETF باسم secsh، ونُشر في شكل RFCs في يناير 2006: البنية في RFC 4251، وطبقة النقل في RFC 4253، ومصادقة المستخدم في RFC 4252، وطبقة الاتصال في RFC 4254. ويكمن الجزء المهم في تقسيم البروتوكول إلى طبقات، لأن ذلك يتيح استبدال كل طبقة على حدة. ويتلخص معظم ما تبقى من هذا التاريخ في تنفيذ عمليات الاستبدال هذه.

تبرز تغييران أساسيان. انتقلت حماية السلامة من CRC-32 إلى HMAC (hash-based message authentication code)، باستخدام مفتاح مشتق من سر مشترك. لذلك لا يستطيع المهاجم الذي لا يمكنه حساب MAC تزوير حزمة. كما انتقلت آلية الاتفاق على المفتاح إلى Diffie-Hellman. في SSH-1، كان العميل يختار مفتاح الجلسة ويرسله مشفراً باستخدام مفاتيح RSA الخاصة بالخادم. لذلك كان أي شخص يحصل لاحقاً على تلك المفاتيح الخاصة قادراً على فك تشفير جلسة مسجّلة. أما Diffie-Hellman فيشتق سراً جديداً لكل جلسة، ولا يُنقل هذا السر عبر الشبكة. لذلك، إذا سُجّل traffic الآن ثم سُرقت host key لاحقاً، فلن ينتج عن ذلك شيء. تُسمى هذه الخاصية forward secrecy.

لا يشترك SSH-2 مع SSH-1 في أي توافق على مستوى wire protocol. ولهذا تغيّر الرقم بدلاً من تغيير الجزء العشري.

لماذا أزيل SSH-1 بدلاً من إصلاحه

استغرقت الإزالة ثلاث إصدارات من OpenSSH. عطّل الإصدار 7.0، في 11 August 2015، البروتوكول 1 افتراضياً وقت التجميع. وأزال الإصدار 7.4، في 19 December 2016، دعم الخادم له. ثم حذف الإصدار 7.6، في 3 October 2017، جانب العميل أيضاً، مع خيارات الإعداد والوثائق المرتبطة به.

كان الإبقاء عليه كخيار للمعدات القديمة سيبدو نهجاً أكثر ملاءمة، لكن كاشف CRC-32 يوضح سبب رفض هذا الخيار. لم يكن من الممكن الوصول إلى تجاوز السعة إلا لأن شيفرة البروتوكول 1 كانت مضمنة وقت التجميع، وكانت موجودة في مسار اعتقد معظم المسؤولين أنه غير مستخدم على أنظمتهم. يمكن الوصول إلى الشيفرة التي تُصدر ضمن البرنامج. أما الشيفرة المحذوفة فلا يمكن الوصول إليها.

لماذا يحذّرك اتصال SSH الأول بشأن مفتاح المضيف

يُثبت التشفير أن حركة الشبكة خاصة. لكنه لا يثبت هوية الطرف الآخر. إذا تمكّن مهاجم من اعتراض المسار وأجاب بدلاً من خادمك، فستحصل على جلسة مشفّرة بالكامل مع المهاجم. يُسمّى ذلك هجوماً من نوع الرجل في الوسط. يعالج SSH ذلك باستخدام مفتاح مضيف: يثبت الخادم أنه يملك الجزء الخاص من زوج المفاتيح، ويتحقق العميل من هذا المفتاح بمقارنته بما سجّله في المرة السابقة. إذا أردت معرفة آلية الاتصال نفسه، فراجع ما يحدث عند فتح اتصال 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])?

تؤدي الإجابة بنعم إلى تخزين ذلك المفتاح في ~/.ssh/known_hosts. في كل اتصال لاحق، يقارن العميل المفتاح بالقيمة المخزّنة. ويؤدي عدم التطابق إلى إصدار أقوى رسالة تحذير يعرضها البرنامج:

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

المعنى الصريح لمطالبة الاتصال الأولى هو أن البروتوكول يقرّ بوجود لحظة ضعف واحدة فيه. يعني مبدأ الثقة عند أول استخدام أن أمان الاتصال الأول لا يتجاوز أمان الشبكة التي أجريته عبرها. يمكنك سد هذه الفجوة. اقرأ بصمة المفتاح من وحدة تحكم مزوّد الخدمة أو من سجل إنشاء الخادم قبل الاتصال. انشر البصمة في DNS كسجل SSHFP وفقاً لـRFC 4255، ولا يستحق ذلك التنفيذ إلا إذا كنت تستخدم DNSSEC. أو وقّع مفاتيح المضيف باستخدام سلطة شهادات (CA) خاصة بك، بحيث تثق الأجهزة العميلة بالـCA بدلاً من الثقة بكل مفتاح على حدة. عملياً، يقبل معظم الأشخاص المطالبة دون التحقق، ومن الأفضل التصريح بذلك بوضوح.

كيف أزاحت المفاتيح العامة كلمات المرور

كان توثيق المفاتيح العامة متاحاً منذ الإصدارات الأولى من SSH، ومع ذلك استغرق اعتماده كإجراء معتاد سنوات. تعتمد الآلية على التشفير غير المتماثل: يثبت العميل أنه يملك مفتاحاً خاصاً عبر توقيع تحدٍّ، ولا يغادر المفتاح الخاص العميل. أما كلمة المرور فتفعل العكس. صحيح أن SSH ينقلها داخل القناة المشفّرة، لكن الخادم يتلقى السر الفعلي، ولذلك ينتهي الأمر بالخادم المخترق أو الخبيث وهو يملك معلومة يمكنه إعادة استخدامها ضدك في أماكن أخرى.

السبب الثاني هو الحسابات الاحتمالية. أي خادم يستمع على المنفذ 22 عبر عنوان عام يتلقى محاولات تسجيل دخول آلية على مدار الساعة، وكلمة المرور سلسلة يمكن تخمينها. أما المفتاح فلا يمكن تخمينه عملياً. يؤدي ضبط PasswordAuthentication no إلى إنهاء هذه الفئة كاملة من الهجمات، ولذلك يظهر في كل قائمة تحقق لتقوية الأمان. لكنه يزيل أيضاً خيار الرجوع الذي كان ينقذك عندما يتعطل المفتاح، لذا تعلّم التمييز بين الأعطال المتعددة التي تظهر جميعها الرسالة Permission denied (publickey) قبل أن تكون أنت من يُمنع من الدخول. يعني العمل من دون كلمات مرور أيضاً تراكم المفاتيح، ويعرض agent الذي يحتفظ بعشرات المفاتيح كل مفتاح منها بالتتابع حتى يصل الخادم إلى حد المحاولات وينهي الاتصال، وهذا سبب فشل تسجيل الدخول بالرسالة Too many authentication failures حتى عند تحميل المفتاح الصحيح. يتناول أساسيات إدارة مفاتيح SSH إنشاء المفاتيح وتدويرها، بينما تتناول تقوية SSH على VPS إعدادات جانب الخادم.

لماذا تستمر قائمة خوارزميات SSH في التغيّر

يتيح البروتوكول متعدد الطبقات إيقاف استخدام الخوارزميات من دون إصدار بروتوكول جديد. وقد استفاد OpenSSH من هذه الإمكانية باستمرار، وتوضح تواريخ الإصدارات سرعة ذلك.

وصل Ed25519 في OpenSSH 6.5 بتاريخ 30 January 2014، إلى جانب cipher ‏chacha20-poly1305 وتنسيق مفتاح خاص تحميه bcrypt. تستمد توقيعات Ed25519 قيمة nonce الخاصة بكل توقيع بطريقة حتمية، لذلك لا يمكن لمولّد أرقام عشوائية ضعيف وقت التوقيع أن يسرّب المفتاح الخاص. وهذا هو بالضبط الأسلوب الذي استُعيدت به مفاتيح DSA وECDSA الخاصة في حوادث حقيقية.

سلكت DSA الاتجاه المعاكس. عطّل OpenSSH 7.0 مفاتيح المضيف والمستخدم ssh-dss أثناء التشغيل في 2015، لأن الخوارزمية محدودة بمفتاح خاص حجمه 160 بت وباستخدام SHA-1. عطّل الإصدار 9.8، بتاريخ 1 July 2024، استخدام DSA وقت الترجمة. وأزاله الإصدار 10.0، بتاريخ 9 April 2025، وفقاً لعبارات المشروع، «استكمالاً لعملية الإيقاف التدريجي التي بدأت في 2015». استغرق الانتقال من التعطيل إلى الحذف عشر سنوات.

لم يختفِ RSA، لكن تنسيق توقيعه القديم اختفى. أوقف OpenSSH 8.8، بتاريخ 26 September 2021، قبول توقيعات RSA المنشأة باستخدام SHA-1 افتراضياً. وتوضح ملاحظات الإصدار السبب صراحةً: SHA-1 مكسور من الناحية التشفيرية، وكان من الممكن تحقيق تصادمات ذات بادئة مختارة بأقل من USD 50,000. إذا صادفت sign_and_send_pubkey: no mutual signature supported أثناء الاتصال بخادم قديم، فهذا هو التغيير المقصود. مفتاحك سليم. لكن خوارزمية التوقيع التي طلبها الطرف الآخر لم تعد آمنة.

تجري العملية نفسها الآن على تبادل المفاتيح، ولكن هذه المرة قبل ظهور التهديد. يمكن تخزين حركة الشبكة الملتقطة اليوم وفك تشفيرها بعد سنوات بواسطة من يمتلك أول حاسوب كمي قادر على ذلك، لذلك كان يجب تغيير اتفاق المفاتيح قبل وجود مثل هذا الحاسوب. جعل OpenSSH 9.0، بتاريخ 8 April 2022، تبادل مفاتيح هجيناً هو الإعداد الافتراضي: يقرن sntrup761x25519-sha512@openssh.com خوارزمية ما بعد الكم بتبادل X25519، لذلك لا تكون النتيجة أضعف من الجزء التقليدي إذا لم تحقق الخوارزمية الجديدة التوقعات. أضاف OpenSSH 9.9، بتاريخ 19 September 2024، mlkem768x25519-sha256، المبني على ML-KEM (آلية تغليف المفاتيح الشبكية الوحدية)، التي وحّدها NIST في 2024. وجعل OpenSSH 10.0 ذلك الإعداد الافتراضي لاتفاق المفاتيح، وتشرح صفحة المشروع الخاصة بما بعد الكم الأسباب. وبدأ 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. يشرح الإعدادات الافتراضية لتبادل مفاتيح SSH ما بعد الكم معنى ذلك عملياً، والإجراء المناسب عند إصداره بواسطة خادم.

ما الذي يعنيه هذا التاريخ للخادم الذي أمامك

لم يتغير الأمر الذي تكتبه إلا قليلاً منذ عام 1995. لكن كل ما تحته تقريباً استُبدل: فحص السلامة، وتبادل المفاتيح، وخوارزميات التوقيع، وقاعدة الشيفرة نفسها. ولم يكن ذلك ممكناً إلا لأن كل استبدال انتهى بإزالة متعمدة، وكل إزالة عطّلت شيئاً لدى أحد المستخدمين.

لذلك يتحدد أمان SSH لديك أساساً وفق الإصدار الذي تستخدمه. تحمل الإعدادات الافتراضية قرارات تحديد الخوارزميات المعروضة والمرفوضة، والتحذيرات التي تراها. يستمر الخادم القديم في عرض كل ما كان إصداره لا يزال يسمح به، ويواصل التفاوض إلى مستوى أدنى ليتوافق مع عميل قديم. اعتباراً من August 2026، الإصدار الحالي هو OpenSSH 10.5، وقد نُشر في 11 August 2026. ويمثل الفرق بين هذا الإصدار والإصدار الموجود على جهاز لم يلمسه أحد منذ ثلاث سنوات حجم المشكلة. ينبغي أن تتحقق منه ضمن الدقائق العشر الأولى على VPS جديد.

FAQ

من أنشأ SSH، ولماذا؟

كتب Tatu Ylönen، وهو باحث في Helsinki University of Technology، بروتوكول SSH في عام 1995 بعد هجوم لالتقاط كلمات المرور على شبكة الجامعة. كانت أدوات تسجيل الدخول عن بُعد في ذلك الوقت، مثل telnet وrlogin، ترسل كلمات المرور عبر الشبكة كنص قابل للقراءة، لذلك كان كل من يراقب مقطعاً مشتركاً يجمع بيانات الاعتماد أثناء مرورها. أصدر البرنامج كبرنامج مجاني في يوليو 1995. وبحلول نهاية ذلك العام، كان لديه نحو 20,000 مستخدم في خمسين دولة، وفي ديسمبر 1995 أسس SSH Communications Security.

ما الفرق بين SSH-1 وSSH-2؟

هما بروتوكولان مختلفان ولا يتوافقان على مستوى السلك. كان SSH-1 بروتوكولاً واحداً متكامل البنية يستخدم CRC-32 لضمان السلامة، وكان العميل يرسل مفتاح جلسة مشفراً باستخدام مفاتيح RSA الخاصة بالخادم. يقسم SSH-2 الوظائف إلى طبقة نقل، وطبقة مصادقة، وطبقة اتصال (RFCs 4251 إلى 4254، يناير 2006)، ويستخدم HMAC لضمان السلامة، ويشتق مفاتيح الجلسة باستخدام Diffie-Hellman، لذلك تبقى حركة الشبكة المسجلة سرية حتى إذا سُرق مفتاح المضيف لاحقاً. أوقف OpenSSH دعم SSH-1 على مراحل، وانتهى ذلك في الإصدار 7.6 في أكتوبر 2017.

لماذا استبدل OpenSSH تطبيق SSH الأصلي؟

انتقل تطوير التطبيق الأصلي إلى منتج تجاري بترخيص مقيّد، وكان آخر إصدار يمكن إعادة استخدامه بحرية هو ssh 1.2.12. في أوائل عام 1999، أعاد Björn Grönvall إحياء ذلك الإصدار باسم OSSH، ثم أنشأ فريق OpenBSD تفرعاً من OSSH باسم OpenSSH، وأصدره مع OpenBSD 2.6 في 1 ديسمبر 1999. احتاج OpenBSD إلى شيفرة خضعت للتدقيق وذات ترخيص غير مقيّد لنظامه الأساسي، وهاتان الخاصيتان هما ما أتاحا لكل نظام تشغيل آخر إصدار التطبيق نفسه عبر الفرع المحمول.

لماذا يسأل SSH عن مفتاح المضيف في أول اتصال؟

لأن العميل لم يسبق له رؤية ذلك الخادم، ولا يملك قيمة يقارن بها مفتاحه. لا يستطيع التشفير وحده التمييز بين خادم سليم وجهاز موجود في وسط المسار، لذلك يعرّف SSH الخوادم باستخدام المفاتيح ويسجل ما رآه في ~/.ssh/known_hosts. يكون الاتصال الأول هو اللحظة الوحيدة التي لا توجد فيها قيمة مخزنة للتحقق منها، ولذلك يسألك العميل بدلاً من ذلك. قارن البصمة ببصمة حصلت عليها من وحدة تحكم المزوّد أو من الخادم نفسه، وتعامل مع أي رسالة لاحقة من نوع 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، كلتا المشكلتين.