سؤال هل يمكنني إضافة مضيف جديد تلقائيًا إلى known_hosts؟


إليكم موقفي: أقوم بإعداد أداة اختبار من شأنها ، من عميل مركزي ، إطلاق عدد من مثيلات الماكينة الافتراضية ثم تنفيذ الأوامر عليها عبر ssh. سيكون لدى الأجهزة الظاهرية أسماء مضيفين وعناوين IP غير مستخدمة من قبل ، لذا لن يكونوا في ~/.ssh/known_hosts ملف على العميل المركزي.

المشكلة التي أواجهها هي أن الأول ssh يأتي الأمر الذي يتم تشغيله ضد مثيل ظاهري جديد دائمًا مع مطالبة تفاعلية:

The authenticity of host '[hostname] ([IP address])' can't be established.
RSA key fingerprint is [key fingerprint].
Are you sure you want to continue connecting (yes/no)?

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


217
2018-04-16 04:15


الأصل


بالنسبة لبيئة اختبار مستقلة بذاتها وآمنة ماديًا ، قد يعمل القبول التلقائي للمفاتيح على ما يرام. ولكن قبول المفاتيح العامة تلقائيًا في بيئة الإنتاج أو عبر شبكة غير موثوق بها (مثل الإنترنت) يتجنب أي حماية ضد هجمات الرجل في الوسط التي قد توفرها SSH. ال فقط طريقة صحيحة للتأكد من أنك آمن ضد هجمات MITM هي التحقق من المفتاح العام للمضيف من خلال قناة موثوقة خارج النطاق. لا توجد طريقة آمنة لأتمتة ذلك دون إعداد بنية أساسية لتوقيع المفتاح معتدلة التعقيد. - Eil


الأجوبة:


تعيين StrictHostKeyChecking خيار ل no، إما في ملف التكوين أو عبر -o :

ssh -o StrictHostKeyChecking=no username@hostname.com


126
2018-04-16 04:34



هذا يتركك مفتوحة للإنسان في الهجمات الوسطى ، ربما ليست فكرة جيدة. - JasperWallace
JasperWallace ، في حين أن هذه عادة نصيحة جيدة ، يجب أن تكون حالة الاستخدام المحددة (نشر اختبار VMs وإرسال الأوامر إليها) آمنة بما فيه الكفاية. - Massimo
هذا يعطي Warning: Permanently added 'hostname,1.2.3.4' (RSA) to the list of known hosts. لتجنب التحذير ، ولتجنب الإدخال المضاف إلى أي ملف known_hosts ، أقوم بما يلي: ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null username@hostname.com - Peter V. Mørch
Downvoting لأن هذا لا يجيب على السؤال ويفتح على نقاط الضعف الأمنية خطيرة. - marcv81
Mnebuerquo: إذا كنت قلقًا بشأن الأمان ، فلن يكون لديك أي شيء على الإطلاق يتعلق بهذا السؤال. سيكون لديك مفتاح المضيف الصحيح أمامك ، الذي تم جمعه من وحدة التحكم في النظام الذي تريد الاتصال به ، ويمكنك التحقق منه يدويًا عند الاتصال الأول. أنت بالتأكيد لن تفعل أي شيء "تلقائيا". - Ignacio Vazquez-Abrams


IMO ، أفضل طريقة للقيام بذلك هي:

ssh-keygen -R [hostname]
ssh-keygen -R [ip_address]
ssh-keygen -R [hostname],[ip_address]
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts

سيضمن ذلك عدم وجود إدخالات مكررة ، بحيث يتم تغطيتك لكل من اسم المضيف وعنوان IP ، وسيتم أيضًا تجزئة المخرجات ، وهو مقياس أمان إضافي.


210
2017-09-27 20:51



لماذا تحتاج كل 3 ssh-keyscan؟ لا يمكنك الحصول عليها فقط مع أول واحد لأنها تعمل لكلا اسم المضيف والملكية الفكرية؟ - Robert
هل يمكنك التأكد من أن الجهاز الذي يرد على طلب ssh-keyscan هو بالفعل الشخص الذي تريد التحدث إليه؟ إذا لم تكن قد فتحت نفسك لرجل في الهجوم الأوسط. - JasperWallace
JasperWallace نعم ، لأنك تحتاج على الأقل إلى البصمة أو حتى المفتاح العام الأفضل ، وفي هذه الحالة يمكنك إضافته مباشرة إلى known_hosts ، مما يحول هذا السؤال الموضوعي. إذا كان لديك فقط بصمة ، سيكون عليك كتابة خطوة إضافية للتحقق من المفتاح العمومي الذي تم تنزيله باستخدام بصمة الإصبع الخاصة بك ...
يدعو ل ssh-keyscan كانت الفشل بالنسبة لي لأن المضيف الهدف الخاص بي لا يدعم نوع المفتاح الافتراضي الإصدار 1. مضيفا -t rsa,dsa إلى الأمر الثابت هذا. - phasetwenty
ربما تكون هذه فكرة سيئة. أنت تفتح نفسك على هجوم رجل في الوسط بتحديث هذه المفاتيح. لتجنب الادخالات المتكررة ، تحقق من حالة الإرجاع ssh-keygen -F [address] في حين أن. medium.com/@wblankenship/... - retrohacker


بالنسبة للكسلات:

ssh-keyscan <host> >> ~/.ssh/known_hosts

80
2017-09-25 10:03



+1 لكونك مذنبًا كما هو مشمول. شكر. - SaxDaddy
عرضة للهجمات MITM. أنت لا تتحقق من بصمة المفتاح. - Mnebuerquo
Mnebuerquo تقول ما يجب القيام به ولكن ليس كيف ، وهو ما سيكون مفيدا. - Jim
jameshfisher نعم هي عرضة لهجمات MITM ، ولكن هل قمت بمقارنة بصمة RSA ، التي تم عرضها لك مع الخادم الفعلي ، عندما كنت تقوم بذلك يدويًا؟ لا؟ إذن هذه الإجابة هي طريقة القيام بذلك من أجلك. إذا كانت الإجابة بنعم ، فلا يجب عليك استخدام هذه الإجابة والقيام بها يدويًا أو تنفيذ إجراءات أمنية أخرى ... - fivef
Mnebuerquo سأكون سعيدًا حقًا إذا سمحت لنا أيضًا بالتعرف على طريقة أفضل للتعامل مع هذا ، عندما نحتاج إلى استنساخ ريبو باستخدام برامج نصية مجمعة دون حضور ، ونريد تجاوز هذه المطالبة. يرجى إلقاء بعض الضوء على حل حقيقي إذا كنت تعتقد أن هذا ليس صحيحًا! - Waqas Shah


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

ssh-keyscan -t rsa,dsa HOST 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts

ما سبق سيؤدي الحيلة لإضافة مضيف ، فقط إذا لم تتم إضافته بعد. كما أنه ليس آمنًا للتزامن ؛ أنت لا يجب تنفيذ القصاصة على نفس الجهاز الأصل أكثر من مرة واحدة في نفس الوقت ، كما يمكن الحصول على الملف tmp_hosts clobbered ، مما يؤدي في النهاية إلى ملف known_hosts تصبح منتفخة ...


38
2018-03-06 09:00



هل هناك طريقة للتحقق ما إذا كان المفتاح في known_hosts قبل  ssh-keyscan؟ والسبب هو أنها تتطلب بعض الوقت واتصالًا إضافيًا بالشبكة. - utapyngo
النسخة الأصلية للملف من هذا الملف cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts، لكن تعديلًا لاحقًا غيره إلى >>. عن طريق >> هو خطأ. فإنه يهزم الغرض من التفرد في السطر الأول ، ويؤدي إلى تفريغ الإدخالات الجديدة في known_hostsفي كل مرة يتم تشغيلها. (فقط نشر تعديلاً لتغييره مرة أخرى.) - paulmelnikow
هذا يخضع لنفس هجمات MITM مثل الآخرين. - Mnebuerquo
سيعطيكutapyngo ssh-keygen -F البصمة الحالية. إذا عاد مرة أخرى فارغة مع رمز إرجاع 1 ، فأنت لا تملك ذلك. إذا طبعت شيئًا ورمز الإرجاع هو 0 ، فهذا يعني أنه موجود بالفعل. - Rich L
إذا كنت تهتم كثيرًا بـ MITM ، فقم بنشر DNSSEC وسجلات SSHFP أو استخدم بعض الوسائل الآمنة الأخرى لتوزيع المفاتيح ، وسيكون حل kludge هذا غير ذي صلة. - Zart


يمكنك استخدام ssh-keyscan الأمر للاستيلاء على المفتاح العام وإلحاق هذا المفتاح الخاص بك known_hosts ملف.


18
2018-04-16 05:09



تأكد من فحص بصمة الإصبع للتأكد من أنها المفتاح الصحيح. وإلا فإنك تفتح نفسك على هجمات MITM. - Mnebuerquo
Mnebuerquo نقطة عادلة في السياق العام ، ولكن لماذا يحاول شخص ما تجميع المفاتيح بشكل برمجي إذا كان يعرف بالفعل ما هو المفتاح الصحيح؟ - Brian Cline
هذه ليست طريقة للقيام بذلك. MITM. - jameshfisher


هذه هي الطريقة التي يمكنك دمجها سه-keyscan في لعبك:

---
# ansible playbook that adds ssh fingerprints to known_hosts
- hosts: all
  connection: local
  gather_facts: no
  tasks:
  - command: /usr/bin/ssh-keyscan -T 10 {{ ansible_host }}
    register: keyscan
  - lineinfile: name=~/.ssh/known_hosts create=yes line={{ item }}
    with_items: '{{ keyscan.stdout_lines }}'

6
2018-02-03 03:12



هل تقوم بتحميل ملف known_hosts صالح معروف ، أم أنك تقوم بـ ssh-keyscan وإلقاء الإخراج في known_hosts دون التحقق من بصمات الأصابع؟ - Mnebuerquo
هذا هو ببساطة مقالب إخراج keyscan ، نعم. لذلك في الواقع هو نفسه StrictHostKeyChecking = لا ، فقط مع تحديث known_hosts الصامت دون تافه بخيارات ssh. لا يعمل هذا الحل أيضًا بشكل جيد نظرًا لقيام ssh-keyscan بإرجاع عدة أسطر مما يؤدي إلى تحديد هذه المهمة دائمًا كـ "تم تغييرها" - Zart
هذه ليست طريقة للقيام بذلك. MITM. - jameshfisher
jameshfisher وسأكون سعيدًا حقًا إذا سمحت لنا أيضًا بالتعرف على طريقة أفضل للتعامل مع ذلك ، عندما نحتاج إلى استنساخ ريبو باستخدام برامج نصية مجمعة دون حضور ، ونريد تجاوز هذه المطالبة. يرجى إلقاء بعض الضوء على حل حقيقي إذا كنت تعتقد أن هذا ليس صحيحًا! واسمحوا لنا أن نعرف "كيف" للقيام بذلك ، إذا كنت تعتقد أن هذه ليست الطريقة الصحيحة للقيام بذلك! - Waqas Shah


لقد واجهت مشكلة مشابهة ووجدت أن بعض الإجابات المقدمة لم تعطني سوى جزء من الحل الآلي. ما يلي هو ما انتهيت به ، وآمل أن يساعد:

ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x

يضيف المفتاح ل known_hosts ولا يطالب بكلمة المرور.


5
2017-10-21 17:27



عرضة للهجمات MITM. أنت لا تتحقق من بصمة الإصبع. - Mnebuerquo
لا أحد يتحقق بصمة. - Brendan Byrd
هذه ليست طريقة للقيام بذلك. MITM. - jameshfisher


هذا سيكون حلا كاملا ، وقبول مفتاح المضيف لأول مرة فقط

#!/usr/bin/env ansible-playbook
---
- name: accept ssh fingerprint automatically for the first time
  hosts: all
  connection: local
  gather_facts: False

  tasks:
    - name: "check if known_hosts contains server's fingerprint"
      command: ssh-keygen -F {{ inventory_hostname }}
      register: keygen
      failed_when: keygen.stderr != ''
      changed_when: False

    - name: fetch remote ssh key
      command: ssh-keyscan -T5 {{ inventory_hostname }}
      register: keyscan
      failed_when: keyscan.rc != 0 or keyscan.stdout == ''
      changed_when: False
      when: keygen.rc == 1

    - name: add ssh-key to local known_hosts
      lineinfile:
        name: ~/.ssh/known_hosts
        create: yes
        line: "{{ item }}"
      when: keygen.rc == 1
      with_items: '{{ keyscan.stdout_lines|default([]) }}'

5
2017-11-23 13:51



هذه ليست طريقة للقيام بذلك. MITM. - jameshfisher


لذلك ، كنت أبحث عن طريقة دنيوية لتجاوز التفاعل اليدوي المضيف غير المعروف لاستنساخ git repo كما هو موضح أدناه:

brad@computer:~$ git clone git@bitbucket.org:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)?

لاحظ بصمة مفتاح RSA ...

لذلك ، هذا هو شيء SSH ، وهذا سوف يعمل على بوابة عبر SSH والأمور المتعلقة SSH فقط بشكل عام ...

brad@computer:~$ nmap bitbucket.org --script ssh-hostkey

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
| ssh-hostkey:
|   1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_  2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds

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

حسن. أنا إما تعرضت للاختراق في أماكن متعددة وآلات فحصتها - أو أن التفسير الأكثر معقولية لكل شيء يتعلق بالجنس المدمن هو ما يحدث.

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

بغض النظر عن ذلك ، عد إلى السلسلة الأصلية التي يمكننا رؤيتها في السياق أدناه.

brad@computer:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg

لذلك ، في وقت مبكر ، لدينا طريقة لطلب شكل تعريف من المضيف الأصلي.

في هذه المرحلة ، نكون يدويًا ضعافًا بشكل تلقائي - تتطابق السلاسل ، ولدينا البيانات الأساسية التي تنشئ بصمة الإصبع ، ويمكننا طلب هذه البيانات الأساسية (منع التصادمات) في المستقبل.

الآن لاستخدام هذه السلسلة بطريقة تمنع السؤال عن أصالة المضيف ...

لا يستخدم ملف known_hosts في هذه الحالة إدخالات نص عادي. ستعرف إدخالات المجزأة عند رؤيتها ، فإنها تبدو مثل التجزئة مع أحرف عشوائية بدلاً من xyz.com أو 123.45.67.89.

brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==

يظهر خط التعليق الأول بشكل يثير غضبًا - ولكن يمكنك التخلص منه من خلال عملية إعادة توجيه بسيطة عبر الاتفاقية ">" أو ">>".

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

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

#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts

لذا ، هكذا ستبقى عذراء لهذا اليوم يمكنك أن تفعل الشيء نفسه مع جيثب باتباع اتجاهات مماثلة في وقتك الخاص.

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

خطأ ssh -oStrictHostKeyChecking = no hostname [command]

خطأ ssh-keyscan -t rsa -H hostname >> ~ / .ssh / known_hosts

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


4
2017-10-05 21:18



أعتقد أن هذا هو أفضل حل لهذه المشكلة. ومع ذلك ، كن حذرا للغاية أثناء استخدام Nmap على شيء ما مثل Amazon EC2 ، تلقيت تحذيرا عن ميناء المسح الذي Nmap! ملء في شكلها قبل القيام portcanning! - Waqas Shah
...حسنا هذا صحيح. أنا لا أعرف لماذا كنت ستفعل مسح المنفذ من EC2. إذا قمت بتسجيل الدخول إلى حسابك ، يمكنك فقط الحصول على المفاتيح من الأجهزة الفعلية. هذا أكثر بالنسبة للآلات التي لا تملك السيطرة عليها. أفترض أن لديك جهاز محلي لا يخضع لقيود مسح ضوئي على منفذ AWS. ولكن ، إذا كنت في حالة حالة حافة حيث يجب تشغيل nmap مع AWS ، أفترض أن هذا التحذير سيكون مفيدًا. - BradChesney79
باستخدام nmap لقراءة مفتاح المضيف SSH من محطة العمل الخاصة بك ومن ثم الوثوق بتلك القيمة لا يختلف عن الاتصال عبر SSH مع إيقاف تشغيل StructHostKeyChecking. انها مجرد عرضة للهجوم رجل في الوسط. - Micah R Ledbetter
... @ MicahRLedbetter وهذا هو السبب في أنني أقترح أن "المزيد من المقارنات من أجهزة الكمبيوتر المختلفة والشبكات سيزيد عادة من قدرتك على الثقة في الاتصال". لكن هذه هي وجهة نظري. إذا كنت تتحقق من المضيف المستهدف من مجموعة من الظروف البيئية فقط ، فكيف ستعرف أي تناقضات؟ هل لديك أي اقتراحات أفضل؟ - BradChesney79
هذا هو مسرح الأمن. القيام بشيء معقد لخلق مظهر أمن أكبر. لا يهم كم عدد الطرق المختلفة التي تستخدمها لطلب المضيف لمفتاحه. مثل السؤال عن نفس الشخص عدة مرات إذا كان بإمكانك الوثوق به (ربما تتصل به ، والبريد الإلكتروني ، والنص ، والبريد العادي). سيقولون دائمًا نعم ، ولكن إذا كنت تسأل الشخص الخطأ ، فلا يهم. - vastlysuperiorman


أقوم بعمل برنامج نصي أحادي الخطوط ، طويل نوعاً ما ولكنه مفيد لجعل هذه المهمة للمضيفين مع عناوين IP متعددة ، وذلك باستخدام dig و bash

(host=github.com; ssh-keyscan -H $host; for ip in $(dig @8.8.8.8 github.com +short); do ssh-keyscan -H $host,$ip; ssh-keyscan -H $ip; done) 2> /dev/null >> .ssh/known_hosts

3
2018-04-18 21:01