क्या हस्ताक्षरित SSH कीपर जैसी कोई चीज है?


9

हम अपने एप्लिकेशन में फ़ाइलों को एक दूरस्थ सर्वर पर स्थानांतरित कर रहे हैं और प्रमाणीकरण की आवश्यक विधि SSH कुंजी का उपयोग करना है।

इसलिए, मैंने ssh-keygen का उपयोग कर अपनी कीपेयर बनाई और रिमोट होस्ट की अधिकृत_की फ़ाइल में प्रविष्टि के लिए अपनी सार्वजनिक कुंजी सबमिट की। हालाँकि, इसे आईटी सुरक्षा ने अस्वीकार कर दिया था जिन्होंने कहा था कि वे मेरे लिए कीपर उत्पन्न करेंगे और मुझे निजी कुंजी भेजेंगे। कारण: "हमें आईटी सुरक्षा टीम द्वारा हस्ताक्षरित एसएसएच कुंजी की आवश्यकता है। यह सुनिश्चित करने के लिए है कि हमारे पास ट्रैकिंग और जवाबदेही में कुछ नेतृत्व है।"

जाहिर है, मेरे पास इसके मुद्दे हैं। किसी और के द्वारा बनाई गई निजी कुंजी होने का मतलब है कि मेरे पास वह व्यक्ति हो सकता है जो मुझे जाने बिना मेरे जैसा बना रहा है। मैं इस तर्क का खंडन करने के तरीके खोजने की कोशिश कर रहा हूं।

जहाँ तक मैं Google कर सकता हूँ, वहाँ कुंजी को हस्ताक्षर करने का कोई ज्ञात तरीका नहीं लगता है कि यह उस व्यक्ति को ट्रैक करने में मदद करता है जिसने हस्ताक्षर किए थे। तथ्य यह है कि मैंने अपनी सार्वजनिक कुंजी जमा की है, जिसका अर्थ है कि मैं कुंजी और किसी को भी, जो उस कुंजी के साथ दूरस्थ सर्वर पर हस्ताक्षर करता है, डिफ़ॉल्ट रूप से स्वयं के रूप में पहचाना जाता है। हस्ताक्षर करने में मदद कैसे होगी? और वे किसी भी रास्ते पर हस्ताक्षर कैसे करेंगे?

अगर मैं गलत हूँ, तो कृपया मुझे कोई सुराग दे, धन्यवाद!


ठीक है, अब जब हमने निर्धारित किया है कि एसएसएच कुंजी पर हस्ताक्षर नहीं किए जा सकते हैं, तो मुझे आईटी सुरक्षा दिखाने की आवश्यकता है कि वे वास्तव में किसका लॉग-इन कर रहे हैं (रचनात्मक होना चाहिए, मुझे लगता है, यदि उच्च-उच्चता शुरू नहीं हुई )। अपने स्वयं के सर्वर पर, मैंने sshd के LogLevel को DEBUG में सेट किया। इसलिए अब जब मैं लॉग इन करता हूं, तो मैं निम्नलिखित स्निपेट देख सकता हूं:

Found matching DSA key: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

यह हैश मान लगता है। मैं इस से कैसे संबंधित करूं कि अधिकृत_की फ़ाइल में किस सार्वजनिक कुंजी का उपयोग किया गया था? मुझे पता है कि एक और पंक्ति है जो कहती है:

debug1: matching key found: file /home/bofh/.ssh/authorized_keys2, line 1

लेकिन यह उतना उपयोगी नहीं है जितना कि लाइन नंबरों को आसानी से बदला जा सकता है अगर मैं मूल कुंजी को नीचे धकेलते हुए फ़ाइल के शीर्ष पर एक कुंजी डालें।

धन्यवाद!


2
हो सकता है कि वे चाबियों को प्रिंट करेंगे, इसे (कागज पर) हस्ताक्षर करेंगे और फिर इसे दूर करेंगे?
इन्नाम

आपके द्वारा प्राप्त किया गया हैश मूल्य सबसे अधिक संभावना है कि कुंजी के तथाकथित फिंगरप्रिंट। मैं सुझाव देता हूं कि आप इन फिंगरप्रिंट्स को कैसे सूचीबद्ध कर सकते हैं, इस बारे में ओपनशेड मैनुअल की जाँच करें।
नील्स बसेजेस

इस नीति का सबसे संभावित कारण यह है कि वे वास्तव में जरूरत पड़ने पर आपको प्रतिरूपण करने में सक्षम होना चाहते हैं। हस्ताक्षर करने का तर्क सिर्फ बीएस है ताकि यह ध्वनि को नियोफाइट्स के लिए प्रशंसनीय बना सके। यहां तक ​​कि अगर उन्हें प्यूबिक पर हस्ताक्षर करने की आवश्यकता होती है, तो भी उन्हें इसे स्वयं उत्पन्न करने की आवश्यकता नहीं होगी।
b0fh

जवाबों:


13

जब से आपने अपना प्रश्न पूछा है, ब्रह्मांड बदल गया है।

Openssh5.4 आप के बाद थे प्रमाण पत्र के लिए समर्थन जोड़ा। अधिक जानकारी के लिए http://www.openssh.org/txt/release-5.4 (और मैन पेज) पर जारी नोट देखें , या यदि आप वास्तव में पागल होना चाहते हैं, तो Gory विवरण के लिए PROTOCOL.certkeys देखें


बस बहुत लंबे समय के बाद यह देखा ... कानूनी लगता है :) यह कोशिश करेंगे, धन्यवाद!
अप्रैल को रात 8:18 पर भक्त

8

आपके प्रश्न को पढ़ते समय मेरी पहली धारणा यह है कि आईटी व्यक्ति को एसएसएच और एसएसएल मिलाया जाता है (यह हमारे द्वारा हस्ताक्षरित होना चाहिए) और यह भी समझ में नहीं आता कि एसएसएल वास्तव में कैसे काम करता है।

वैसे भी एसएसएच कुंजी पर हस्ताक्षर करने का कोई तरीका नहीं है (जो मुझे पता है)।


+1 आप उसी तरह से ssh कीज़ पर हस्ताक्षर नहीं कर सकते हैं जिस तरह से आप PGP या SSL प्रमाणपत्र पर हस्ताक्षर कर सकते हैं। मैं उनसे स्पष्टीकरण चाहता हूँ।
डेविड पशले

4

इस अनुरोध में कुछ सही नहीं है।

यदि यह सर्वर पर हस्ताक्षरित फ़ाइलों को वितरित कर
रहा है , तो मुझे उम्मीद है कि यह नंगे न्यूनतम पर किया जाएगा।

  1. आप अपने लिए एक की-पेयर बनाएं (इसे मेरी-की को कॉल करें)
    • जब आप कुछ भेजना चाहते हैं,
    • आप पहले इसे एन्क्रिप्ट करें my-key-private
    • फिर सर्वर पर इस एन्क्रिप्टेड फ़ाइल को अपलोड किया गया
    • सर्वर पर किसी को इस तरह की प्रक्रिया को उल्टा करना पड़ता है,
    • वे my-key-pubफ़ाइल को डिक्रिप्ट करने के लिए आपका उपयोग करते हैं
    • यदि आपने फ़ाइल भेजी है, तो डिक्रिप्ट उसे पुनर्प्राप्त कर देगा
    • अन्यथा, उन्हें कोई उपयोग करने योग्य फ़ाइल नहीं मिलेगी
    • प्रभावी रूप से, आपने अपनी निजी कुंजी के साथ फाइल पर हस्ताक्षर किए हैं
    • उन्होंने आपकी सार्वजनिक कुंजी के साथ हस्ताक्षर का सत्यापन किया है
    • जवाबदेही उनके द्वारा यह पुष्टि की जाती है कि आपने फ़ाइल भेज दी है

ऐसी चीजें करने के बारे में जाने के अन्य तरीके हैं,
हालांकि, किसी अन्य व्यक्ति द्वारा उत्पन्न की-जोड़ी प्राप्त करना प्रमाणीकरण योजना के रूप में बेकार है
इसका एक मजबूत निहितार्थ है कि आप उन पर उतना ही भरोसा करते हैं जितना आप खुद पर भरोसा करते हैं।


ये शुरुआती सवाल हैं जो आप अपने आईटी से पूछ सकते हैं।
यदि आईटी के लिए जवाबदेही एक चिंता है ,

  1. वे कैसे सुनिश्चित करते हैं कि आप उनके द्वारा दी गई कुंजी-जोड़ी को साझा / ढीला नहीं करते हैं? तथा,
    • यह की-जोड़ी-आईटी अवधारणा आईटी द्वारा आपको दिए गए पासवर्ड से कैसे भिन्न है।
      उस मामले में मुख्य-जोड़े से क्यों परेशान होते हैं।

आप फ़ाइलों को एन्क्रिप्ट करने के लिए PGP / GnuPG के बारे में सोच रहे हैं। इस मामले में मुख्य हस्ताक्षर सामान्य है। मूल प्रश्न SSH कुंजी के बारे में है। यह समझ में आता है अगर वे एक PGP हस्ताक्षरित / एन्क्रिप्टेड SSH कुंजी (एक दूसरे की PGP कुंजियों का सत्यापन और हस्ताक्षर करने के बाद) के लिए पूछ रहे थे।
pgs

@ पीजी, मैं यह देखने की कोशिश कर रहा हूं कि आईटी व्यक्ति यहां क्या लक्षित कर रहा है।
निक

मुझे पूरा यकीन है कि सुरक्षा लड़का उलझन में है, लेकिन चूंकि वह मेरे ग्राहक की कंपनी से आईटी सिक्योरिटी लड़का है और मेरे सहयोगी नहीं है, इसलिए मुझे थोड़ा और चातुर्य बनाने की जरूरत है और रचनात्मक रूप से डब्ल्यू / ओ को उस पर हंसने और यह कहने की ज़रूरत है कि उसे चीजें मिल गई हैं मिश्रित। हां, यह निश्चित रूप से एसएसएच है और पीजीपी नहीं।
16 फरवरी को

@ फॉफिट, टैक्टफुल होना जहाँ मेरे अंतिम बिंदु आपकी मदद करेंगे।
निक

@ लाभ, आपका लक्ष्य अंत में उन्हें यह एहसास दिलाना होगा कि उन्हें अपनी मंशा को सही ढंग से हासिल करने के लिए क्या करना होगा।
निक

2

कोई कारण नहीं है कि आप नंगे कुंजी के बजाय SSH प्रमाणीकरण के लिए X.509 प्रमाण पत्र का उपयोग नहीं कर सकते हैं - वास्तव में, मैं बहुत पसंद करूँगा अगर OpenSSH ने इस तरह से काम किया हो! लेकिन, ओपनएसएसएच का स्टॉक संस्करण नहीं है, और यह इन दिनों प्रभावी कार्यान्वयन है।

मैंने ओपनएसएसएच के कुछ गढ़े हुए संस्करणों को देखा है, जो चारों ओर तैरते हैं, और वाणिज्यिक SSH.com कार्यान्वयन भी X.509 प्रमाणीकरण का समर्थन करता है। इसलिए, यदि आपका संगठन इनमें से किसी एक का उपयोग कर रहा है, तो यह आवश्यक है कि केंद्रीय प्राधिकरण द्वारा कुंजियों पर हस्ताक्षर किए जाएं।

उस ने कहा, तीसरे पक्ष द्वारा उत्पन्न की जाने वाली निजी कुंजी की आवश्यकता के लिए कोई बहाना नहीं है! यदि वे X.509 मार्ग पर जा रहे हैं, तो उन्हें आपके पास एक कीपर और प्रमाण पत्र पर हस्ताक्षर करने का अनुरोध उत्पन्न करना चाहिए, जैसे कि आप SSL के लिए उपयोग किए जाने वाले किसी अन्य X.509 प्रमाणपत्र के साथ करेंगे, आदि।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.