سؤال لا تقم بإضافة hostkey إلى known_hosts لـ SSH


أريد الاتصال بمضيف عبر SSH لكنني لا أريد إضافة اسم المضيف إلى ~/.ssh/known_hosts.

كيف أقوم بذلك؟


94
2018-05-15 00:03


الأصل




الأجوبة:


إذا كنت تريد هذا السلوك لأنك تعمل مع خوادم سحابية (AWS EC2 ، Rackspace CloudServers الخ) أو كنت تقوم بتوفير صور جديدة باستمرار في Vagrant ، فقد ترغب في تحديث تهيئة SSH بدلاً من إضافة أسماء مستعارة bash أو المزيد من الخيارات على سطر الأوامر.

فكر في إضافة شيء مثل:

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET
  • استخدم صارمًا للتعبير العادي للمضيف بقدر الإمكان ليكون آمنًا.
  • سيحدد إعداد LogLevel إلى QUIET التحذير الذي ذكره Guillaume من الظهور

83
2018-06-07 00:28



يجب عليك فعلًا عدم تعطيل StrictHostKeyChecking بشكل كامل ، لذا فإن إجابة cclark هي حل وسط كبير للعمل مع خوادم السحاب. - Alex Recarey
لقد أثبت هذا الأمر أنه مفيد للغاية بالنسبة لي حيث كنت أستخدم Shipit (أداة نشر JavaScript) ضد Vagrant. لم أتمكن من الوصول بسهولة إلى المعلمات التي مرت بها Shipit إلى SSH ، مما سمح لي بتجنب هذه الأداة وإخبارها بما فعلت ولم أكن أريد أن أتذكره. - John Munsch
LogLevel هو ما كنت أبحث عنه. لديه ميزة إضافية لعدم إظهار إشعار الشركة تكوين عند تشغيل البرامج النصية! (أقوم الآن بتشغيل w / loglevel ERROR) - Anshu Prateek
في أي ملف أقوم بإضافة هذا؟ - Wim Deblauwe
هذا هو ملف تكوين SSH الخاص بك. في Linux أو macOS ، سيكون الملف بشكل عام في دليل يسمى .ssh داخل الدليل الرئيسي ويسمى config - ~ / .ssh / config - cclark


-o "UserKnownHostsFile /dev/null"

يجب أن تعمل.


79
2018-05-15 00:30



يعمل على النحو المقصود ، ولكنه سيبلغ دائمًا: "تحذير: تمت إضافة" اسم المضيف ، ip "(RSA) إلى قائمة المضيفات المعروفة بشكل دائم." أنا جعلت هذا يذهب بعيدا مع: 2> & 1 | grep -v "^Warning: Permanently added" - Guillaume Boudreau
هذا هو ما احتاجه لسيناريو بلدي - لا DNS ، LAN مع DHCP ، وأجهزة الكمبيوتر الحصول على عناوين مختلفة في كل وقت. سوف أحتاج إلى كتابة "نعم" طوال الوقت ، إلا أنه أمر رائع. - Tomasz Gandor
add -o "LogLevel ERROR" ولن يشتكي من التحذيرات بعد الآن - John
ملاحظة: طلب منع تلك الرسالة "تحذير: إضافة دائمًا" اسم المضيف ، ip '(RSA) إلى قائمة المضيفات المعروفة. " تم الإبلاغ عنها للمشرفين bugzilla.mindrot.org/show_bug.cgi؟id=2413 - Ben Creasy
الأنابيب ل grep سوف دمج stdout و stderr؛ أيضا يمكن أن تتغير حالة الخروج. في حالة استخدام bash، سيكون من الأفضل استخدام عملية الاستبدال للتخلص من الرسالة: ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]. سوف يتجنب الأنبوب وبالتالي التغييرات المقابلة في معالجة حالة الخروج. - Alex O


أشعر أن إضافة مفتاح المضيف إلى known_hosts الخاص بك (الأشخاص الذين يقومون بتشغيل هذه الخدمات ، في تجربتي ، على الأقل الذكية بما فيه الكفاية للحفاظ على مفاتيح المضيف الخاصة بهم متسقة بين الأجهزة التي تخدم نفس اسم المضيف) ثم تشغيل StrictHostKeyChecking ، إيقاف CheckHostIP ، و سوف يمنحك تسجيل الدخول مع خطأ LogLevel أفضل تجربة دون التضحية بالأمان. (حسنًا ، بدون CheckHostIP ، يجب عليك الوثوق بنظام أسماء النطاقات DNS ، وهو عبارة عن ثقب ضخم لا يحتوي على DNSSEC أو شيء مماثل ؛ ولكننا سنكتسح ذلك تحت السجادة في الوقت الحالي).

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

ما أستخدمه:

Host github.com *.github.com
StrictHostKeyChecking yes
CheckHostIP no
LogLevel ERROR

أود من هذه الخدمات أن تنشر مفاتيح المضيف SSH الخاصة بهم على مواقعهم الإلكترونية عبر HTTPS ، حتى أتمكن من نسخها بشكل واضح دون الحاجة إلى الاتصال أولاً واحتمال تعرض نفسي لهجوم MITM.


8
2018-05-20 17:40





أقترح

LogLevel ERROR

على

LogLevel QUIET

لذا لا يزال بإمكانك الحصول على "تعذر حل اسم المضيف" وأخطاء أخرى مماثلة


5
2018-01-24 00:19



يجب أن تكون قادراً على الثقة في اتصالات SSH الخاصة بك ، imho. لا تجعل الأمر صامتًا بشأن المخاطر. - sylvainulg
يعتمد حقا. لدينا بيئات تطوير تتعرض للتدمير كل أسبوع وإعادة بنائها ، وتظل سجلات A الخاصة بها كما هي ، ولكن يتم إنشاء مفتاح المضيف الخاص بها في كل مرة يتم إنشاؤها فيه. لا يمكننا الاستمرار في مفاتيح المضيف لأن سجل A يتم تعريفه فقط في قاعدة بيانات تستند إلى اسم بيئة ، ويمكن إلغاء أسماء البيئة أو يتم إنشاء أسماء جديدة في أي وقت ، لذلك يكون الحل أعلاه مفيدًا بشكل حقيقي. - Alex Berry


لجلسة واحدة ssh ، استخدم هذا

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host

3
2017-12-16 05:54



لا يضيف هذا شيئًا جديدًا إلى إجابة مقبولة على سؤال عمره 5 سنوات. - JakeGould


هل حاولت تعطيل StrictHostKeyChecking؟ يمكنك ان تفعل ذلك مع -o الخيار أو في ملف التكوين ~/.ssh/config.


2
2018-05-15 00:11



أنا بالفعل استخدم ذلك. ولكن له تأثير مختلف: فهو يقلل من صرامة فحص مفتاح المضيف. أي. عندما يكون المضيف غير معروف ، فإنه لا يزال يربط عند تعطيل هذا الخيار. وبالتالي ، فإنه لا يزال يحفظ المضيف. ولكن أعتقد أنني وجدت الحل الصحيح (انظر جوابي). - Albert


لقد وجدت إدخالات .ssh / config التالية مفيدة (LAN مع DHCP و DNS):

 CheckHostIP no

 Host *.*
 CheckHostIP yes

النتيجة هي أن أسماء الماكينات المحلية "zora" أو "goron" لن تتحقق من عناوين IP التي تم تعيينها ديناميكيًا ، ولكن www.mycompany.com أو node42.planetlab.com سيظل تأكيد عناوين IP الثابتة الخاصة بهم.


0
2018-01-23 09:19