تاريخ 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 بعنوان "هجمات المراقبة المستمرة للشبكات". أفاد التحذير بأن متسللين استولوا على معلومات الوصول إلى عشرات الآلاف من الأنظمة عبر الإنترنت. كانت الأداة المستخدمة تضع واجهة الشبكة في وضع 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، وهو مجموع اختباري صُمم لاكتشاف أخطاء الإرسال، لا لمقاومة المهاجم. في عام 1998، أوضح Ariel Futoransky وEmiliano Kargieman من CORE SDI عواقب ذلك. عند استخدام أنماط التشفير CBC أو CFB مع فحص CRC-32، يستطيع مهاجم يعرف أقل من 16 بايت من النص الصريح إدخال نص مشفّر يختاره، ويقبله الطرف المستقبل على أنه أصلي. وهذا يعني تشغيل أوامر على الخادم.

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

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

تبرز تغييران أساسيان. انتقلت سلامة البيانات من CRC-32 إلى HMAC، أي رمز مصادقة الرسائل المعتمد على التجزئة، والمفتاح بسر مشترك. لذلك لا يستطيع المهاجم الذي لا يمكنه حساب MAC تزوير حزمة. كما انتقلت آلية الاتفاق على المفتاح إلى Diffie-Hellman. في SSH-1، كان العميل يختار مفتاح الجلسة ويرسله مشفراً باستخدام مفاتيح RSA الخاصة بالخادم، ولذلك كان أي شخص يحصل لاحقاً على تلك المفاتيح الخاصة قادراً على فك تشفير جلسة مسجلة. أما Diffie-Hellman فيشتق سراً جديداً لكل جلسة ولا يُنقل عبر الشبكة، لذلك لا تؤدي مراقبة traffic الآن ثم سرقة مفتاح المضيف لاحقاً إلى أي نتيجة. وتُسمى هذه الخاصية السرية المستقبلية.

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

سبب إزالة 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])?

تؤدي الإجابة بـ yes إلى تخزين ذلك المفتاح في ~/.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 إلى إنهاء فئة الهجمات بأكملها، ولذلك يظهر في كل قائمة للتحصين الأمني. يتناول أساسيات إدارة مفاتيح 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-bit وعلى 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، المشكلتين.