سؤال "إضافة مفتاح مضيف صحيح في known_hosts" / مفاتيح SSH متعددة المضيف لكل اسم مضيف؟


عند محاولة الدخول إلى جهاز كمبيوتر أسيطر عليه ، أتلقى رسالة مألوفة:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
[...].
Please contact your system administrator.
Add correct host key in /home/sward/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/sward/.ssh/known_hosts:86
RSA host key for [...] has changed and you have requested strict checking.
Host key verification failed.

لقد قمت بالفعل بتغيير المفتاح. وقرأت بضع عشرات المنشورات التي تقول إن طريقة حل هذه المشكلة هي عن طريق حذف المفتاح القديم من known_hosts ملف.

ولكن ما أود أن يكون هو قبول ssh كل من المفتاح القديم والمفتاح الجديد. اللغة في رسالة الخطأ ("Add correct host key") يقترح أنه يجب أن يكون هناك طريقة لإضافة مفتاح المضيف الصحيح دون إزالة المفتاح القديم.

لم أتمكن من معرفة كيفية إضافة مفتاح المضيف الجديد دون إزالة المفتاح القديم.

هل هذا ممكن أم أن رسالة الخطأ مضللة للغاية؟


121
2017-10-13 14:01


الأصل


هذا هو مفتاح المضيف الذي يقوم بتوليد الخطأ. يجب أن يكون للمضيف مفتاح واحد فقط. هذا ليس له علاقة مع العميل أو مفاتيح المستخدم. هل لديك عنوان IP واحد يطفو بين مضيفين مختلفين أو شيء ما؟ - David Schwartz
في حالتي ، أعلم أنني سأتحول بين المفتاحين كثيرًا في المستقبل القريب بينما نعبث ببعض الأشياء. يبدو هذا مفيدًا أيضًا في عنوان IP واحد مع موقف المضيفين العديدين الذين تقترحهم. أساسا أريد فقط أن أعرف ما إذا كان هذا ممكن لتعليمي الخاص بغض النظر عن أي تطبيق عملي معين. - Samuel Edwin Ward


الأجوبة:


  1. الحصول على مفتاح rsa الخاص بخادمك:

    $ ssh-keyscan -t rsa server_ip
    # server_ip SSH-2.0-OpenSSH_4.3
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    
  2. وعلى العميل ، أضف هذا المفتاح إلى ~/.ssh/known_hosts:

    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAqx9m529...(the offending key)
    server_ip ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwH5EXZG...
    

126
2017-10-13 14:38



هذا العمل! ومع ذلك ، فأنا أستخدم "HashKnownHosts" ، لذلك بدا الإدخال قليلاً خارج المكان. لحسن الحظ ssh_config (5) أشار لي إلى ssh-keygen (1) الذي أوضح أنه يمكنني استخدام "ssh-keygen -H" لتجزئة الإدخالات unhashed. شكرا لكم! - Samuel Edwin Ward
هذا "يعمل" ولكنك لا تتحقق من المفتاح ، لذلك أنت عرضة لهجمات mitm ... - JasperWallace
JasperWallace ، طالما يتم الخطوة الأولى عبر اتصال آمن (على سبيل المثال باستخدام مضيف محلي) يجب أن يكون آمنًا جدًا ، أعتقد - ony
هل هناك أي طريقة لجمع كل أنواع المفاتيح من الخادم؟ أحيانًا لا تعرف ما إذا كانت RSA و DSA و ECDSA و RSA1 ... إلخ. - Sopalajo de Arrierez
SopalajodeArrierez كما يقول manpage يمكنك فصل أنواع مع الفواصل ، لذلك لا ssh-keyscan -t rsa1,dsa,rsa,ecdsa,ed25519 server_ip - ولكن السبب الوحيد للعثور عليه rsa1 و dsa المفاتيح هي تحديد الخوادم التي تحتاج إلى ترقية / إعادة تهيئة - kbolino


قم بإزالة هذا الإدخال من known_hosts باستخدام:

ssh-keygen -R *ip_address_or_hostname*

سيؤدي ذلك إلى إزالة عنوان IP أو اسم المضيف الذي يمثل مشكلة من known_hosts ملف ومحاولة الاتصال مرة أخرى.

من صفحات الرجل:

-R hostname
  يزيل جميع المفاتيح التي تنتمي إلى اسم المضيف من ملف known_hosts. يعد هذا الخيار مفيدًا في حذف المضيفات المجزأة (راجع الخيار -H   في الاعلى).


74
2018-02-09 06:49



"كيفية إضافة مفتاح المضيف الجديد دون إزالة المفتاح القديم." - Samuel Edwin Ward
هذا هو الحل الافضل ! - Thomas Decaux
كيف يكون هذا 19 صوتًا؟ لا يقترب من الإجابة على السؤال المطروح .. - Molomby
يأتي سؤالك للمرة الثانية عندما أستخدم google لـ "git ssh update host key automatically". هذه الإجابة هي ما كنت أبحث عنه. فتح سؤال جديد مع ما أريده تمامًا ، قد يجعله مغلقًا كنسخة مكررة. - Jason Goemaat
اسم المضيف يعمل أيضا - damluar


طريقة بسيطة للغاية هي:

cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak

ثم تحرير known_hosts لمسح المفتاح الأصلي ، ثم ssh إلى المضيف باستخدام:

ssh name@computer

سيضيف المفتاح الجديد تلقائيًا ؛ ثم قارن بين الملفين. برنامج مثل meld طريقة لطيفة لمقارنة الملفين. ثم دمج الملفات لجعل known_hosts تحتوي على كلا المفتاحين

"السبب" وراء الاحتفاظ بمفتاحين هو أن نظام الوجهة متعدد أنظمة التشغيل ، على الرغم من أنني أجرؤ على القول بأن هناك طريقة لمزامنة المفاتيح عبر عمليات التثبيت ، يبدو الأمر أكثر وضوحًا للسماح بمفاتيح متعددة.

تصحيح 2015/06

يجب أن أضيف ، إعادة النظر فيه الآن ، لألاحظ طريقة أكثر بساطة [طالما كان الإدخال قابلاً للتحديد ، عادةً من عنوان المضيف / عنوان IP جانباً من رسالة الخطأ التي تشير إلى موقعه المحدد] ؛

  1. تحرير known_hosts لإضافة # في بداية الإدخال "القديم" في known_hosts مؤقتا
  2. اتصل [ssh بالمضيف] ، وافق على المطالبة بإضافة المفتاح الجديد "تلقائيًا"
  3. ثم أعد تعديل known_hosts لإزالة #

هناك حتى الخيار HostKeyAlias ​​كما هو الحال في

ssh -o HostKeyAlias=mynewaliasforthemachine name@computer

ثم في وقت لاحق، بعد ويضيف العميل سه مفتاح جديد تحت اسم مستعار، قد إما تحرير known_hosts لبديلا عن "الحقيقي" عنوان اسم المضيف / IP من أجل الاسم المستعار أو الاتصال التي تجسد التي تستضيف مع الأبد الخيار الاسم المستعار


16
2018-04-30 22:29



هذا "مزيج"؟ meldmerge.org - Samuel Edwin Ward
هذا هو meld :) apt-get / yum ببساطة يتم خلط اسم التثبيت - Mark
لقد قمت بعمل صيغة مختلفة من اقتراحك تعمل بشكل جيد - بدلاً من cp ، mv ، ثم ssh ، ثم cat ~ / .ssh / known_hosts.bak ~ / .ssh / known_hosts> tmp؛ mv tmp ~ / .ssh / known_hosts - Peter N Lewis


لدي نفس المشكلة مع pi التوت الذي أحصل عليه مع عدة أنظمة مختلفة (نظام dev لتجميع ثنائيات الذراع ، والمشروع ، xbmc ، الخ) وقد واجهت نفس المشكلة. يستخدمون DHCP على شبكة محلية ويقوم جهاز التوجيه الخاص بي بإعادة استخدام نفس عنوان IP نفسه منذ أن كان عنوان MAC كما هو. لقد قمت بحلها باستخدام أسماء نطاقات مختلفة في ملف المضيف الخاص بي:

10.10.10.110 pi-dev
10.10.10.110 pi-xbmc
10.10.10.110 pi-etc

يحفظ ملف known_hosts بصمات الأصابع حسب اسم المضيف حتى على الرغم من أنه هو نفس عنوان IP ، يحصل كل اسم مضيف فريد على إدخال مختلف.

لقد سئمت من إضافة الأسماء إلى ملفات المضيفات في كل مرة استخدمت فيها نظامًا جديدًا لذا توصلت إلى طريقة أكثر كسلًا باستخدام الأصفار البادئة على عناوين IP مثل:

$ ssh pi@10.10.10.110
$ ssh pi@010.10.10.110
$ ssh pi@10.010.10.110

يحصل كل شكل من عناوين IP (uncunonicalized) على إدخال خاص به في known_hosts.


7
2017-11-04 02:28



حصلت على OpenSSH الناس حكيمة لي ، لم تعد تعمل هذه الثغرة في الإصدارات الأحدث. - Mike
يمكنك استخدام CheckHostIP no في ~/.ssh/config لتكون قادرة على الاستمرار في استخدام الثغرة. يمكنك حتى تعريف الأسماء المستعارة الخاصة بك هناك حتى لا تضطر إلى العزف مع /etc/hosts وتعريف CheckHostIP no فقط لأسماء المضيفات الثلاثة هذه. - GnP


إذا كان لدى كل من العميل والخادم OpenSSH 6.8 أو أحدث ، فيمكنك استخدام UpdateHostKeys yes الخيار في الخاص بك ssh_config أو ~/.ssh/config. فمثلا:

Host *
    UpdateHostKeys yes

هذا يجعل مخزن SSH جميع مفاتيح المضيف التي يجب على الخادم القيام بها known_hostsوعندما يقوم الخادم بتغيير أو إزالة مفتاح مضيف واحد ، يتم تغيير أو إزالة المفتاح أيضًا في known_hosts.


2
2017-09-22 04:28



هذا هو الجواب الأكثر فائدة! على الرغم من أنها لا تقدم بشكل صريح طريقة لحل السؤال الأصلي إذا تم تغيير مفتاح مضيف بالفعل ، فإن جميع الإجابات الأخرى غير آمنة لأنها لا تتحقق من مفتاح المضيف الجديد. يتيح لك هذا الخيار إجراء التمرير الآمن إلى مفاتيح المضيف الجديدة. - Jaap Eldering


لا أرى سبب رغبتك في العمل مع مفتاحين ، ولكن يمكنك بالتأكيد إضافة أكثر من مفتاح واحد صحيح إلى ~/.ssh/known_hosts الملف ، ولكن عليك القيام بذلك يدويا.

حل آخر قد يكون استخدام StrictHostKeyChecking=no خيار لهذا المضيف المحدد:

ssh -o StrictHostKeyChecking=no user@host

التي يمكنك وضعها في اسم مستعار في حياتك ~/.profile أو شيئا من هذا القبيل.

alias hc=ssh -o StrictHostKeyChecking=no user@host

1
2017-10-13 14:49



لا يبدو StrictHostKeyChecking للمساعدة في هذه الحالة؛ على ما يبدو يحدد السلوك فقط عندما لا يكون المضيف في ملف known_hosts. مذكور هنا: gossamer-threads.com/lists/openssh/dev/45349#45349 - Samuel Edwin Ward
إنها تعمل هنا. سوف تحصل على التحذير ، لكن تسجيل الدخول مستمر. - Sven♦
هذا غريب. هل تستخدم مصادقة كلمة المرور؟ هل تستخدم OpenSSH؟ - Samuel Edwin Ward


اذا أنت فقط ssh على شبكة محلية ثم ...

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

على سبيل المثال

cp known_hosts known_hosts.old
rm known_hosts
nano known_hosts

ثم اضغط الفضاء ، backspace cntl + x و 'y' لحفظ المخزن المؤقت الجديد (ملف). ممارسته السيئة ، لكن بخير توفيرها لا تكون منتظمة خارج الشبكة المحلية الخاصة بك (مثل uni أو خادم العمل)

على شبكة محلية آمنة هذا آمن لأنك ببساطة لا تستطيع الحصول على رجل في الهجوم الأوسط.

من الأفضل دائمًا استخدام الرمز الذي تفهمه!


0
2018-06-15 21:44



مسح كامل known_hosts الملف في كل مرة سوف ينفي معظم الأمن الذي قدمته ssh. - kasperd
في الواقع ، يمكنني القول أنه في شبكة داخلية آمنة ، من الأفضل أن نفهم الكود الخاص بك ونتحايل على الأمان بدلاً من نسخ الكود بلا داع. على شبكة خارجية فإن الوضع سيكون مختلفا. - Aaron


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

إليك تقنية بسيطة تسمح لك بمغادرة المضيف الصارم أثناء التحقق ، ولكن قم بتحديث المفتاح بطريقة متحكم بها ، عندما تقوم بذلك توقع لتغييره:

  • قم بإزالة المفتاح القديم وتحديثه في أمر واحد

    ssh-keygen -R server.example.com && \
        ssh -o StrictHostKeyChecking=no server.example.com echo SSH host key updated.
    
  • كرر ذلك مع عنوان (عناوين) IP أو أسماء المضيف الأخرى إذا كنت تستخدمها.

ميزة هذا الأسلوب هو أنه rekeys الملقم بالضبط مرة واحدة. يبدو أن معظم إصدارات ssh-keygen لا تقوم بإرجاع خطأ إذا كان الخادم الذي تحاول حذفه غير موجود في ملف hosts المعروف ، إذا كانت هذه مشكلة بالنسبة لك ، فاستخدم الأمرين بالتسلسل.

يتحقق هذا النهج أيضًا من الاتصال ويبعث برسالة لطيفة للسجلات في الأمر ssh (الذي يسجل الدخول ويحدّث مفتاح المضيف والمخرجات تم تحديث مفتاح المضيف SSH ثم يخرج على الفور.

إذا كان إصدار ssh-keygen الخاص بك بإرجاع رمز إنهاء غير صفري ، وكنت تفضل معالجة هذا بدون أخطاء ، بغض النظر عن أو اتصال مسبق ، ما عليك سوى استخدام الأمرين في التسلسل ، مع تجاهل أية أخطاء في الأمر ssh-keygen.

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


-1
2017-09-18 01:56





كان لي نفس المشكلة.

كل ما فعلته هو sudo nano /home/user/.ssh/ host_allow ومحو المفتاح.

عندما أعود إلى الخادم مرة أخرى أضافت مفتاح جديد.


-3
2018-05-18 11:31



بعض المعلومات حول سبب حدوث ذلك ستكون مفيدة للإجابة. - Drew Khoury