क्या मैं स्वचालित रूप से ज्ञात_होस्ट्स में एक नया होस्ट जोड़ सकता हूं?

Question

यहां मेरी स्थिति है: मैं एक परीक्षण हार्नेस स्थापित कर रहा हूं, जो एक केंद्रीय ग्राहक से, कई वर्चुअल मशीन इंस्टेंसेस लॉन्च करेगा और फिर उन पर कमांड निष्पादित करेगा ssh। वर्चुअल मशीन में पहले अप्रयुक्त होस्टनाम और आईपी पते होंगे, इसलिए वे ~/.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)?

क्या कोई ऐसा तरीका है जिससे मैं इसे दरकिनार कर सकता हूँ और नए मेजबान को पहले से ही ग्राहक मशीन के लिए जाना जा सकता है, शायद एक सार्वजनिक कुंजी का उपयोग करके जो पहले से ही वर्चुअल मशीन छवि में बेक हो गया है? अगर मैं कर सकता हूं तो मैं वास्तव में एक्सपेक्ट या जो भी इंटरेक्टिव प्रॉम्प्ट का जवाब देने के लिए उपयोग करने से बचना चाहता हूं।

Comments

एक परीक्षण वातावरण के लिए जो स्व-निहित है और शारीरिक रूप से सुरक्षित है, स्वचालित कुंजी स्वीकृति बस ठीक काम कर सकती है। लेकिन स्वचालित रूप से उत्पादन के माहौल में या एक अविश्वसनीय नेटवर्क (जैसे कि इंटरनेट) में सार्वजनिक कुंजी को स्वीकार करना पूरी तरह से मानव-में-बीच के हमलों के खिलाफ किसी भी संरक्षण को दरकिनार कर देता है जो एसएसएच अन्यथा वहन करेगा। यह सुनिश्चित करने का एकमात्र वैध तरीका है कि आप MITM हमलों के खिलाफ सुरक्षित हैं, कुछ आउट-ऑफ-बैंड विश्वसनीय चैनल के माध्यम से होस्ट की सार्वजनिक कुंजी को सत्यापित करना है। एक मामूली जटिल कुंजी हस्ताक्षर बुनियादी ढांचे की स्थापना के बिना इसे स्वचालित करने का कोई सुरक्षित तरीका नहीं है।

— ईआईएल

Answer 1

कॉन्फ़िगरेशन फ़ाइल में या इसके माध्यम से StrictHostKeyCheckingविकल्प सेट करें :no-o

ssh -o StrictHostKeyChecking=no [e-mail]

Comments

यह आपको मध्य हमलों में आदमी के लिए खुला छोड़ देता है, शायद एक अच्छा विचार नहीं है।

— जैस्परवर्ल्स

@ जैस्परवैलस, जबकि यह आमतौर पर अच्छी सलाह है, विशिष्ट उपयोग के मामले (परीक्षण वीएम को तैनात करना और उन्हें आदेश भेजना) पर्याप्त सुरक्षित होना चाहिए।

— मैसिमो

यह Warning: Permanently added 'hostname,1.2.3.4' (RSA) to the list of known hosts.चेतावनी से बचने के लिए, और किसी भी ज्ञात_होस्ट फ़ाइल में जोड़ी जा रही प्रविष्टि से बचने के लिए, मैं करता हूं:ssh -o StrictHostKeyChecking=no -o LogLevel=ERROR -o UserKnownHostsFile=/dev/null [e-mail]

— पीटर वी। मॉर्क

डाउनवोटिंग के रूप में यह सवाल का जवाब नहीं देता है और गंभीर सुरक्षा कमजोरियों के लिए खुलता है।

— marcv81

@Mnebuerquo: यदि आप सुरक्षा के बारे में चिंतित थे तो आपके पास इस प्रश्न के साथ करने के लिए कुछ भी नहीं होगा। आपके सामने सही मेजबान कुंजी होगी, जिस सिस्टम से आप कनेक्ट करना चाहते थे, उसके कंसोल से इकट्ठा किया गया था, और आप पहले कनेक्ट करने पर इसे मैन्युअल रूप से सत्यापित करेंगे। आप निश्चित रूप से कुछ भी "स्वचालित रूप से" नहीं करेंगे।

— इग्नासियो वाज़केज़-अब्राम्स

Answer 2

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

यह सुनिश्चित करेगा कि कोई डुप्लिकेट प्रविष्टियां नहीं हैं, कि आप होस्टनाम और आईपी पते दोनों के लिए कवर किए गए हैं, और आउटपुट, एक अतिरिक्त सुरक्षा उपाय भी होगा।

Comments

आपको सभी 3 ssh-keycan की आवश्यकता क्यों है? होस्टनाम और आईपी दोनों के लिए काम करने के बाद क्या आप पहले वाले से नहीं मिल सकते?

— रॉबर्ट

क्या आप सुनिश्चित कर सकते हैं कि ssh-keycan अनुरोध का जवाब देने वाली मशीन वास्तव में वह है जिससे आप बात करना चाहते हैं? यदि आपने अपने आप को बीच के हमले में एक आदमी के लिए नहीं खोला है।

— जैस्परवर्ल्स

@JasperWallace हाँ, इसके लिए आपको कम से कम फ़िंगरप्रिंट या बेहतर सार्वजनिक कुंजी की आवश्यकता होती है, इस स्थिति में आप इसे सीधे जाने-माने में जोड़ सकते हैं, जिससे यह प्रश्न बदल जाता है। यदि आपके पास केवल फ़िंगरप्रिंट है, तो आपको एक अतिरिक्त चरण लिखना होगा जो आपके फ़िंगरप्रिंट के साथ डाउनलोड की गई सार्वजनिक कुंजी को सत्यापित करता है ...

ssh-keyscanमेरे लिए कॉल विफल हो रहे थे क्योंकि मेरा लक्ष्य होस्ट डिफ़ॉल्ट संस्करण 1 कुंजी प्रकार का समर्थन नहीं करता है। -t rsa,dsaकमांड में जोड़ने से यह तय हो गया।

— फस्सेवेंटी

यह शायद एक बुरा विचार है। आप इन कुंजियों को अपडेट करके अपने आप को एक आदमी के बीच में हमले के लिए खोल रहे हैं। डुप्लिकेट प्रविष्टियों से बचने के लिए, बदले की स्थिति की जांच करें ssh-keygen -F [address]। medium.com/@wblankenship/…

— 3

Answer 3

आलसी लोगों के लिए:

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

-उन्होंने होस्टनाम / आईपी एड्रेस को हैश किया

Comments

"ssh-keyscan -H <host> >> ~ / .ssh / ज्ञात_होस्ट" एक प्रविष्टि अधिक पैदा करता है जैसे ssh उपयोगकर्ता के साथ बातचीत करता है। (-एच ने रिमोट होस्ट का नाम बताया।)

— सारा मेसर

MITM हमलों के लिए कमजोर। आप कुंजी फिंगरप्रिंट की जाँच नहीं कर रहे हैं।

— Mnebuerquo

@Mnebuerquo आप कहते हैं कि क्या करना है लेकिन कैसे नहीं, जो मददगार होगा।

— रे

@jameshfisher हाँ इसके MITM हमलों के प्रति संवेदनशील है, लेकिन क्या आपने कभी RSA फिंगरप्रिंट की तुलना की है, जो आपको सर्वर के वास्तविक एक के साथ दिखाया गया था, जब आप मैन्युअल रूप से ऐसा कर रहे थे? नहीं? तो यह जवाब आपके लिए इसे करने का तरीका है। यदि हाँ, तो आपको इस उत्तर का उपयोग नहीं करना चाहिए और इसे मैन्युअल रूप से करना चाहिए या अन्य सुरक्षा उपायों को लागू करना चाहिए ...

— पांचवीं

@Mnebuerquo: मुझे वास्तव में खुशी होगी यदि आप हमें इसे संभालने का एक बेहतर तरीका भी बताएंगे, जब हमें बैच स्क्रिप्ट का उपयोग करके रेपो क्लोन करने की आवश्यकता होती है, जिसमें हमने भाग लिया था और हम इस प्रॉम्प्ट को बाय-पास करना चाहते हैं। कृपया वास्तविक समाधान पर कुछ प्रकाश डालें यदि आपको लगता है कि यह सही नहीं है!

— वकास शाह

Answer 4

जैसा कि उल्लेख किया गया है, कुंजी-स्कैन का उपयोग करना सही और विनीत तरीका होगा।

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 फ़ाइल क्लोएबर्ड हो सकती है, अंततः ज्ञात_होस्ट फ़ाइल के लिए अग्रणी बन रही है ...

Comments

क्या यह जांचने का एक तरीका है कि कुंजी पहले से ज्ञात_होस्ट्स में है या नहीं ssh-keyscan? कारण यह है कि इसके लिए कुछ समय और अतिरिक्त नेटवर्क कनेक्शन की आवश्यकता होती है।

— utapyngo

इस फ़ाइल के मूल पोस्टर का संस्करण था cat ~/.ssh/tmp_hosts > ~/.ssh/known_hosts, लेकिन एक बाद के संपादन ने इसे बदल दिया >>। उपयोग करना >>एक त्रुटि है। यह पहली पंक्ति में विशिष्टता के उद्देश्य को पराजित करता है, और यह known_hostsहर बार चलने वाली नई प्रविष्टियों को डंप करने का कारण बनता है । (बस इसे वापस बदलने के लिए एक संपादन पोस्ट किया गया।)

— पॉलमेलनिकोव

यह दूसरों के समान MITM हमलों के अधीन है।

— Mnebuerquo

@utapyngo ssh-keygen -F आपको वर्तमान फिंगरप्रिंट देगा। यदि यह 1 के रिटर्न कोड के साथ खाली आता है, तो आपके पास यह नहीं है। यदि यह कुछ प्रिंट करता है और रिटर्न कोड 0 है, तो यह पहले से मौजूद है।

— रिच एल

यदि आप MITM के बारे में बहुत परवाह करते हैं, DNSSEC और SSHFP रिकॉर्ड्स को तैनात करें या कुंजियों को वितरित करने के कुछ अन्य सुरक्षित साधनों का उपयोग करें और यह कीचड़ समाधान अप्रासंगिक होगा।

— ज़ार्ट

Answer 5

आप ssh-keyscanसार्वजनिक कुंजी को हथियाने के लिए कमांड का उपयोग कर सकते हैं और इसे अपनी known_hostsफ़ाइल में जोड़ सकते हैं।

Comments

सुनिश्चित करें कि आपने सही कुंजी है यह सुनिश्चित करने के लिए फिंगरप्रिंट की जांच की। अन्यथा आप अपने आप को MITM हमलों तक खोल देते हैं।

— Mnebuerquo

@ Mnebuerquo मेला सामान्य संदर्भ में इंगित करता है, लेकिन अगर वे पहले से ही जानते हैं कि सही कुंजी क्या थी, तो कोई प्रोग्राम को कुंजीपूर्वक इकट्ठा करने की कोशिश क्यों करेगा?

— ब्रायन क्लाइन

यह ऐसा करने का तरीका नहीं है। MITM।

— Jameshfisher

Answer 6

इस तरह आप ssh-keycan को अपने नाटक में शामिल कर सकते हैं:

---
# 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 }}'

Comments

क्या आप किसी ज्ञात मान्य_होस्ट फ़ाइल को अपलोड कर रहे हैं, या आप ssh-keycan कर रहे हैं और आउटपुट को ज्ञात_होल्स में डंप कर रहे हैं, बिना उंगलियों के निशान को सत्यापित किए?

— Mnebuerquo

यह बस एक कुंजी का उत्पादन डंप है, हाँ। तो प्रभाव में यह StrictHostKeyChecking = के समान है, बस ssh विकल्प के साथ fiddling के बिना अद्यतन किए जाने वाले चुप ज्ञात_होस्ट के साथ। यह सॉल्यूशन ssh-keycan की कई लाइनों को लौटाने के कारण भी अच्छा काम नहीं करता है, जिसके कारण इस कार्य को हमेशा 'परिवर्तित' के रूप में चिह्नित किया जाता है

— Zart

यह ऐसा करने का तरीका नहीं है। MITM।

— Jameshfisher

@jameshfisher मुझे वास्तव में खुशी होगी यदि आप हमें इसे संभालने का एक बेहतर तरीका भी बताएंगे, जब हमें बैच स्क्रिप्ट का उपयोग करके रेपो क्लोन करने की आवश्यकता होती है, जिसमें हमने भाग लिया था और हम इस प्रॉम्प्ट को बाय-पास करना चाहते हैं। कृपया वास्तविक समाधान पर कुछ प्रकाश डालें यदि आपको लगता है कि यह सही नहीं है! कृपया इसे करने के लिए "कैसे" जानते हैं, अगर आपको लगता है कि यह करने का सही तरीका नहीं है!

— वकास शाह

यह ज्ञात_होस्ट में मान जोड़ने का एक सर्वथा मान्य तरीका है, लेकिन हाँ यह MITM के लिए अतिसंवेदनशील है। हालाँकि, आंतरिक उपयोग के लिए यह ठीक है।

— कैमरन लोवेल पामर

Answer 7

यह एक संपूर्ण समाधान होगा, केवल पहली बार होस्ट कुंजी स्वीकार करना

#!/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([]) }}'

Comments

यह ऐसा करने का तरीका नहीं है। MITM।

— jameshfisher

Answer 8

मेरे पास एक समान मुद्दा था और पाया गया कि प्रदान किए गए कुछ जवाबों ने मुझे एक स्वचालित समाधान का हिस्सा बना दिया। निम्नलिखित है जो मैंने प्रयोग करके समाप्त किया, आशा है कि यह मदद करता है:

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

यह कुंजी को जोड़ता है known_hostsऔर पासवर्ड के लिए संकेत नहीं देता है।

Comments

MITM हमलों के लिए कमजोर। आप फिंगरप्रिंट की जाँच नहीं कर रहे हैं।

— Mnebuerquo

कोई भी फिंगरप्रिंट की जांच नहीं करता है।

— ब्रेंडन बर्ड

यह ऐसा करने का तरीका नहीं है। MITM।

— jameshfisher

Answer 9

इसलिए, मैं नीचे दिखाए गए एक git रेपो की क्लोनिंग के unkown होस्ट मैनुअल इंटरैक्शन को बायपास करने के लिए एक सांसारिक तरीके की खोज कर रहा था:

brad@computer:~$ git clone [e-mail]: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

सबसे पहले, अपने दैनिक ड्राइवर पर नैम्प स्थापित करें। नैम्प कुछ चीजों के लिए अत्यधिक मददगार है, जैसे खुले बंदरगाहों का पता लगाना और यह-- मैन्युअल रूप से 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

इसलिए, समय से पहले, हमारे पास मूल मेजबान से पहचान का एक तरीका पूछने का एक तरीका है।

इस बिंदु पर हम मैन्युअल रूप से स्वचालित रूप से असुरक्षित हैं - स्ट्रिंग्स मैच, हमारे पास आधार डेटा है जो फिंगरप्रिंट बनाता है, और हम भविष्य में उस आधार डेटा (टकराव को रोकने) के लिए पूछ सकते हैं।

अब उस तार का उपयोग इस तरह से करना है कि एक मेजबान प्रामाणिकता के बारे में पूछने से रोकता है ...

इस मामले में ज्ञात_होस्ट फ़ाइल सादी एंटेक्स्ट प्रविष्टियों का उपयोग नहीं करती है। जब आप उन्हें देखते हैं, तो आपको हैशेड प्रविष्टियां पता होंगी, वे 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==

पहली टिप्पणी लाइन infuriatingly से पता चलता है - लेकिन आप ">" या ">>" सम्मेलन के माध्यम से एक साधारण पुनर्निर्देशन से छुटकारा पा सकते हैं।

जैसा कि मैंने "होस्ट" और विश्वास की पहचान करने के लिए उपयोग किए जाने वाले डेटा को प्राप्त करने के लिए अपनी पूरी कोशिश की है, मैं इस पहचान को मेरी ~ / .shsh निर्देशिका में मेरी ज्ञात_होस्ट फ़ाइल में जोड़ दूंगा। चूँकि अब इसे एक ज्ञात होस्ट के रूप में पहचाना जाएगा, इसलिए जब आप एक यंगस्टर थे, तो मुझे उपर्युक्त संकेत नहीं मिलेगा।

मेरे साथ चिपके रहने के लिए धन्यवाद, यहाँ आप जाते हैं। मैं बिटबकेट 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 = कोई होस्टनाम [आदेश]

गलत ssh-keyscan -t rsa -H hostname >> ~ / .ssh / ज्ञात_होस्ट

कृपया उपरोक्त चीजों में से कोई भी काम न करें। आपको मध्य आक्रमण में एक व्यक्ति के माध्यम से अपने डेटा स्थानान्तरण से बचने की संभावना को बढ़ाने का अवसर दिया जाता है - उस अवसर को लें। अंतर शाब्दिक रूप से सत्यापित कर रहा है कि आपके पास RSA कुंजी bona fide सर्वर में से एक है और अब आप जानते हैं कि उन्हें तुलना करने के लिए उस जानकारी को कैसे प्राप्त करें ताकि आप कनेक्शन पर भरोसा कर सकें। बस याद रखें कि विभिन्न कंप्यूटरों और नेटवर्क से अधिक तुलना आमतौर पर कनेक्शन पर भरोसा करने की आपकी क्षमता में वृद्धि करेगी।

Comments

मुझे लगता है कि यह इस समस्या का सबसे अच्छा समाधान है। हालाँकि, अमेज़ॅन EC2 जैसी किसी चीज़ पर Nmap का उपयोग करते समय बहुत सावधान रहें, मुझे उस पोर्ट स्कैनिंग के बारे में एक चेतावनी मिली जो Nmap करता है! पोर्ट्सकेनिंग करने से पहले उनके फॉर्म भरें!

— वकास शाह

...अच्छी तरह से हाँ। मुझे नहीं पता कि आप EC2 से पोर्ट स्कैनिंग क्यों करेंगे। यदि आप अपने खाते में लॉग इन हैं, तो आप वास्तविक मशीनों से चाबी प्राप्त कर सकते हैं। यह उन मशीनों के लिए अधिक है जिन पर आपका नियंत्रण नहीं है। मुझे लगता है कि आप एक स्थानीय मशीन का उपयोग करने के लिए AWS पोर्ट स्कैनिंग प्रतिबंध के अधीन नहीं होगा। लेकिन, यदि आप उस एज केस स्थिति में हैं, जहां आपको AWS के साथ नैप चलाना होगा, तो मुझे लगता है कि यह चेतावनी सहायक होगी।

— ब्रैडकिसने79

अपने कार्य केंद्र से SSH होस्ट कुंजी को पढ़ने के लिए नैम्प का उपयोग करना और फिर उस मान पर भरोसा करना जो SSH के माध्यम से कनेक्ट करने से अलग नहीं है जैसे कि PathHostKeyChecking बंद हो गया। यह सिर्फ एक आदमी के बीच में हमले के लिए असुरक्षित है।

— मीका आर लेडबेटर

... @ MicahRLedbetter यही कारण है कि मैंने सुझाव दिया है कि "विभिन्न कंप्यूटरों और नेटवर्क से अधिक तुलना आमतौर पर कनेक्शन पर भरोसा करने की आपकी क्षमता में वृद्धि होगी"। लेकिन, यह मेरी बात है। यदि आप कभी भी पर्यावरण की स्थिति के एक सेट से अपने लक्ष्य होस्ट की जांच करते हैं, तो आप किसी भी विसंगतियों के बारे में कैसे जान पाएंगे? क्या आपके पास कोई बेहतर सुझाव था?

— ब्रैडकिसने79

यह सुरक्षा रंगमंच है। अधिक से अधिक सुरक्षा की उपस्थिति बनाने के लिए कुछ जटिल करना। इससे कोई फर्क नहीं पड़ता कि आप मेजबान से इसकी कुंजी के लिए पूछने के लिए कितने अलग-अलग तरीकों का उपयोग करते हैं। जैसे एक ही व्यक्ति से कई बार पूछना अगर आप उन पर भरोसा कर सकते हैं (हो सकता है कि आप कॉल, ईमेल, टेक्स्ट और घोंघा मेल)। वे हमेशा हाँ कहेंगे, लेकिन अगर आप गलत व्यक्ति से पूछ रहे हैं, तो कोई बात नहीं।

— विनीलसुपरियोरमॉन

Answer 10

मैं एक-लाइनर स्क्रिप्ट करता हूं, थोड़ी देर के लिए, लेकिन मल्टीप्ल आईपी, उपयोग 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

Answer 11

निम्नलिखित ~ / .ssh / ज्ञात_होस्ट में डुप्लिकेट प्रविष्टियों से बचें:

if ! grep "$(ssh-keyscan github.com 2>/dev/null)" ~/.ssh/known_hosts > /dev/null; then
    ssh-keyscan github.com >> ~/.ssh/known_hosts
fi

Comments

यह ऐसा करने का तरीका नहीं है। MITM।

— jameshfisher

मुझे यह उत्तर सबसे अच्छा लगा। बिना किसी महत्व के यादृच्छिक वीपीएस के प्रारंभिक सेटअप की स्क्रिप्टिंग के लिए लेकिन मेरे लिए, MITM जोखिम गायब है। Infinitesimal वक्रोक्ति ... पहली पंक्ति की आवश्यकता हैmkdir -p ~/.ssh/known_hosts;

— मार्टिन Bramwell

Answer 12

आप इन मशीनों का निर्माण कैसे कर रहे हैं? क्या आप डीएनएस अपडेट स्क्रिप्ट चला सकते हैं? क्या आप एक IPA डोमेन से जुड़ सकते हैं?

FreeIPA यह स्वचालित रूप से करता है, लेकिन अनिवार्य रूप से आपको सभी की आवश्यकता है SSHFP dns रिकॉर्ड्स और DNSSEC आपके ज़ोन पर (freeipa कॉन्फ़िगर करने योग्य विकल्प के रूप में प्रदान करता है (डिफ़ॉल्ट रूप से अक्षम dnssec))।

आप अपने होस्ट से मौजूदा SSHFP रिकॉर्ड चलाकर प्राप्त कर सकते हैं।

ssh-keygen -r jersey.jacobdevans.com

jersey.jacobdevans.com SSHFP में 1 1 4d8589de6b1a48e148d8fc9fbb967f1b29f53ebc jersey.jacobdevans.com SSHFP में 1 2 6503272a11ba6d7fec2518c02dfed88f3d455ac7786ee5dbd72df63307209d55 jersey.jacobdevans.com SSHFP में 3 1 5a7a1e8ab8f25b86b63c377b303659289b895736> jersey.jacobdevans.com SSHFP 3 में 2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b

फिर एक बार प्रकाशित होने पर, आप VerifyHostKeyDNS yesअपने ssh_config या ~ / .ssh / config में जोड़ देंगे

यदि / जब Google DNSSEC पर फ्लिप करने का निर्णय लेता है, तो आप एक hostkey प्रॉम्प्ट के बिना ssh कर सकते हैं।

ssh jersey.jacobdevans.com

लेकिन मेरे डोमेन पर अभी तक हस्ताक्षर नहीं किए गए हैं, इसलिए अभी के लिए आप देखेंगे ...।

debug1: सर्वर होस्ट कुंजी: ecdsa-sha2-nistp256 SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2kkkT0s

डीबग 1: डीएनएस में 4 असुरक्षित उंगलियों के निशान मिले

debug1: मिलान होस्ट कुंजी फिंगरप्रिंट

DNS में मिला होस्ट 'jersey.jacobdevans.com (2605: 6400: 10: 434 :: 10)' की प्रामाणिकता स्थापित नहीं की जा सकती है। ECDSA कुंजी फिंगरप्रिंट SHA256: H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s है। DNS में पाया जाने वाला मेजबान कुंजी फिंगरप्रिंट। क्या आप वाकई कनेक्ट करना जारी रखना चाहते हैं (हां / नहीं)? नहीं

Answer 13

इसे ठीक से करने के लिए, आप वास्तव में क्या करना चाहते हैं VM की मेजबान सार्वजनिक कुंजी को इकट्ठा करें क्योंकि आप उन्हें बनाते हैं और उन्हें known_hostsप्रारूप में एक फ़ाइल में छोड़ देते हैं । फिर आप -o GlobalKnownHostsFile=...उस फ़ाइल की ओर इशारा करते हुए, यह सुनिश्चित करने के लिए उपयोग कर सकते हैं कि आप उस होस्ट से कनेक्ट कर रहे हैं जिसे आप मानते हैं कि आपको कनेक्ट करना चाहिए। आप यह कैसे करते हैं यह इस बात पर निर्भर करता है कि आप वर्चुअल मशीन कैसे सेट कर रहे हैं, हालाँकि, लेकिन वर्चुअल फाइल सिस्टम को पढ़ना, यदि संभव हो, या यहां तक /etc/ssh/ssh_host_rsa_key.pubकि कॉन्फ़िगरेशन के दौरान सामग्री को प्रिंट करने के लिए होस्ट प्राप्त करना भी चाल हो सकता है।

उस ने कहा, यह सार्थक नहीं हो सकता है, इस बात पर निर्भर करता है कि आप किस प्रकार के वातावरण में काम कर रहे हैं और आपके प्रत्याशित विरोधी कौन हैं। ऊपर दिए गए कई अन्य उत्तरों में वर्णित एक सरल "स्टोर ऑन फर्स्ट कनेक्ट" (एक स्कैन के माध्यम से या पहले "वास्तविक" कनेक्शन के दौरान) करना काफी आसान हो सकता है और फिर भी कुछ सुरक्षा प्रदान कर सकता है। हालाँकि, यदि आप ऐसा करते हैं, तो मैं आपको -o UserKnownHostsFile=...विशेष रूप से इस विशेष परीक्षण स्थापना के लिए विशिष्ट फ़ाइल ( ) के लिए उपयोगकर्ता ज्ञात होस्ट फ़ाइल ( ) को बदलने का सुझाव देता हूं ; यह आपकी व्यक्तिगत ज्ञात होस्ट फ़ाइल को परीक्षण जानकारी के साथ प्रदूषित करने से बचाएगा और जब आप अपने वीएम को हटाते हैं तो अब बेकार सार्वजनिक कुंजियों को साफ करना आसान हो जाएगा।

Answer 14

यह पूरा

• ssh-कुंजी-स्कैन
• ssh-प्रति-आईडी
• ECSDA प्रमुख चेतावनी

व्यवसाय मुझे परेशान करता रहा इसलिए मैंने चुना

उन सभी पर शासन करने के लिए एक स्क्रिप्ट

यह स्क्रिप्ट का एक प्रकार है https://askubuntu.com/a/949731/129227 जिसमें अमुदू का जवाब https://serverfault.com/a/858957/162693 एक लूप में है।

उदाहरण कॉल

./sshcheck somedomain site1 site2 site3

स्क्रिप्ट नाम साइटों पर लूप करेगी और .ssh / config और .ssh / ज्ञात_होस्ट्स फ़ाइल को संशोधित करेगा और अनुरोध पर ssh-copy-id करेगा - अंतिम सुविधा के लिए बस ssh टेस्ट कॉल को विफल होने दें जैसे 3 बार दर्ज करके हिट करें पासवर्ड का अनुरोध।

sshcheck स्क्रिप्ट

#!/bin/bash
# WF 2017-08-25
# check ssh access to bitplan servers

#ansi colors
#http://www.csc.uvic.ca/~sae/seng265/fall04/tips/s265s047-tips/bash-using-colors.html
blue='\033[0;34m'  
red='\033[0;31m'  
green='\033[0;32m' # '\e[1;32m' is too bright for white bg.
endColor='\033[0m'

#
# a colored message 
#   params:
#     1: l_color - the color of the message
#     2: l_msg - the message to display
#
color_msg() {
  local l_color="$1"
  local l_msg="$2"
  echo -e "${l_color}$l_msg${endColor}"
}

#
# error
#
#   show an error message and exit
#
#   params:
#     1: l_msg - the message to display
error() {
  local l_msg="$1"
  # use ansi red for error
  color_msg $red "Error: $l_msg" 1>&2
  exit 1
}

#
# show the usage
#
usage() {
  echo "usage: $0 domain sites"
  exit 1 
}

#
# check known_hosts entry for server
#
checkknown() {
  local l_server="$1"
  #echo $l_server
  local l_sid="$(ssh-keyscan $l_server 2>/dev/null)" 
  #echo $l_sid
  if (! grep "$l_sid" $sknown) > /dev/null 
  then
    color_msg $blue "adding $l_server to $sknown"
    ssh-keyscan $l_server >> $sknown 2>&1
  fi
}

#
# check the given server
#
checkserver() {
  local l_server="$1"
  grep $l_server $sconfig > /dev/null
  if [ $? -eq 1 ]
  then
    color_msg $blue "adding $l_server to $sconfig"
    today=$(date "+%Y-%m-%d")
    echo "# added $today by $0"  >> $sconfig
    echo "Host $l_server" >> $sconfig
    echo "   StrictHostKeyChecking no" >> $sconfig
    echo "   userKnownHostsFile=/dev/null" >> $sconfig
    echo "" >> $sconfig
    checkknown $l_server
  else
    color_msg $green "$l_server found in $sconfig"
  fi
  ssh -q $l_server id > /dev/null
  if [ $? -eq 0 ]
  then
    color_msg $green "$l_server accessible via ssh"
  else
    color_msg $red "ssh to $l_server failed" 
    color_msg $blue "shall I ssh-copy-id credentials to $l_server?"
    read answer
    case $answer in
      y|yes) ssh-copy-id $l_server
    esac
  fi
}

#
# check all servers
#
checkservers() {
me=$(hostname -f)
for server in $(echo $* | sort)
do
  os=`uname`
  case $os in
   # Mac OS X
   Darwin*)
     pingoption=" -t1";;
    *) ;;
  esac

  pingresult=$(ping $pingoption -i0.2 -c1 $server)
  echo $pingresult | grep 100 > /dev/null
  if [ $? -eq 1 ]
  then 
    checkserver $server
    checkserver $server.$domain
  else
    color_msg $red "ping to $server failed"
  fi
done
}

#
# check configuration
#
checkconfig() {
#https://askubuntu.com/questions/87449/how-to-disable-strict-host-key-checking-in-ssh
  if [ -f $sconfig ]
  then
    color_msg $green "$sconfig exists"
    ls -l $sconfig
  fi
}

sconfig=~/.ssh/config
sknown=~/.ssh/known_hosts

case  $# in
  0) usage ;;
  1) usage ;;
  *) 
    domain=$1 
    shift 
    color_msg $blue "checking ssh configuration for domain $domain sites $*"
    checkconfig
    checkservers $* 
    #for server in $(echo $* | sort)
    ##do
    #  checkknown $server 
    #done
    ;;
esac

Answer 15

यहाँ मेजबान का संग्रह कैसे करना है

मेजबानों के संग्रह को परिभाषित करें

ssh_hosts:
  - server1.domain.com
  - server2.domain.com
  - server3.domain.com
  - server4.domain.com
  - server5.domain.com
  - server6.domain.com
  - server7.domain.com
  - server8.domain.com
  - server9.domain.com

फिर ज्ञात मेजबानों की कुंजी जोड़ने के लिए दो कार्यों को परिभाषित करें:

- command: "ssh-keyscan {{item}}"
   register: known_host_keys
   with_items: "{{ssh_hosts}}"
   tags:
     - "ssh"

 - name: Add ssh keys to know hosts
   known_hosts:
     name: "{{item.item}}"
     key: "{{item.stdout}}"
     path: ~/.ssh/known_hosts
   with_items: "{{known_host_keys.results}}"

Answer 16

सबसे अच्छा होगा कि आप प्रत्येक नए सर्वर / होस्ट के फिंगरप्रिंट की जांच करेंगे। यह सर्वर को प्रमाणित करने का एकमात्र तरीका है। इसके बिना, आपका एसएसएच कनेक्शन एक मध्य-मध्य हमले के अधीन हो सकता है ।

यदि आप वास्तव में सुनिश्चित हैं कि आप फ़िंगरप्रिंट की जाँच करना अनदेखा करना चाहते हैं, तो दूसरा सबसे अच्छा, कम सुरक्षित विकल्प का उपयोग करना है StrictHostKeyChecking=accept-new, जिसे ओपनएसएसएच संस्करण 7.6 (2017-10-03) में पेश किया गया था :

पहले "स्वीकार-नया" स्वचालित रूप से hitherto-unseen कुंजियों को स्वीकार करेगा लेकिन परिवर्तित या अमान्य होस्टकी के लिए कनेक्शन से इंकार कर देगा।

पुराने मूल्य का उपयोग न करें StrictHostKeyChecking=noजो कभी भी सर्वर की प्रामाणिकता की जांच नहीं करता है। (हालांकि इस =noसेटिंग का अर्थ बाद में कुछ रिलीज़ फ़्लिप किया जाएगा ।)