334

GitHub साइट पर एक लिंक है ...

https://help.github.com/articles/generating-ssh-keys

... और यह बताता है ...

यदि आपने अनुशंसित HTTPS पद्धति का उपयोग नहीं करने का निर्णय लिया है, तो हम आपके कंप्यूटर और GHHub के बीच एक सुरक्षित कनेक्शन स्थापित करने के लिए SSH कुंजियों का उपयोग कर सकते हैं। नीचे दिए गए चरण आपको SSH कुंजी जनरेट करके और फिर आपके GitHub खाते में सार्वजनिक कुंजी जोड़कर चलेंगे।

अनुशंसित विधि HTTPS क्यों है? क्या SSH विधि में किसी प्रकार की सुरक्षा खामी है या यह धीमी है? मैंने SSH कुंजी बनाई है, तो क्या यह किसी सुरक्षा चिंताओं को कम करेगा?

— जॉन लिवरमोर
स्रोत

39

कम कॉन्फ़िगरेशन का मतलब आसान है, शायद। इसके अलावा, कुछ अवर ऑपरेटिंग सिस्टम में डिफ़ॉल्ट रूप से SSH क्लाइंट भी नहीं होते हैं।

— कैटस्पॉज

45

इस थ्रेड को खोजने वाले भावी उपयोगकर्ताओं के लिए: GitHub ने अपनी नीति बदल दी है और अब कहता है "हम GitHub के साथ बातचीत करते समय SSH कनेक्शन का उपयोग करने की दृढ़ता से सलाह देते हैं।"

— दाढ़ी वाले क्लिंजेक

9

@StevePomeroy, मुझे नहीं लगता कि उस स्थान पर "दृढ़ता से अनुशंसा" बयान मौजूद है।

— नोएल अब्राहम

5

@BonsaiOak यह पृष्ठ पर स्टीव पोमेरॉय से जुड़ा हुआ था - web.archive.org/web/20140321204642/https://help.github.com/… - पर इस्तेमाल किया गया था, लेकिन ऐसा लगता है कि उन्होंने इसे तब से बदल दिया है।

— दाढ़ी

5

@ br3nt सही है। वे इसकी सिफारिश नहीं करते थे। फिर उन्होंने किया। फिर वे फिर से नहीं किया। यही कारण है कि मेरा लिंक एक

— आर्काइव.ऑर्ग

192

GitHub ने कई बार ( उदाहरण ) अपनी सिफारिश बदल दी है ।

ऐसा प्रतीत होता है कि वे वर्तमान में HTTPS की अनुशंसा करते हैं क्योंकि यह नेटवर्क और प्लेटफ़ॉर्म की सबसे विस्तृत श्रृंखला पर स्थापित करना सबसे आसान है, और उन उपयोगकर्ताओं द्वारा जो इस सब के लिए नए हैं।

SSH में कोई अंतर्निहित दोष नहीं है (यदि वे इसे निष्क्रिय कर देते थे) - नीचे दिए गए लिंक में, आप देखेंगे कि वे अभी भी SSH कनेक्शन के बारे में विवरण प्रदान करते हैं:

HTTPS के एक फ़ायरवॉल द्वारा अवरुद्ध होने की संभावना कम है।

https://help.github.com/articles/which-remote-url-should-i-use/

Https: // क्लोन URL सभी रिपॉजिटरी, सार्वजनिक और निजी पर उपलब्ध हैं। ये URL हर जगह काम करते हैं - भले ही आप फ़ायरवॉल या प्रॉक्सी के पीछे हों।
HTTPS कनेक्शन credential.helperआपके पासवर्ड को कैश करने की अनुमति देता है।

https://help.github.com/articles/set-up-git

यह जानना अच्छा है: क्रेडेंशियल हेल्पर केवल तब काम करता है जब आप HTTPS रेपो URL को क्लोन करते हैं। यदि आप इसके बजाय SSH रेपो URL का उपयोग करते हैं, तो SSH कुंजियों का उपयोग प्रमाणीकरण के लिए किया जाता है। हालांकि हम इसकी अनुशंसा नहीं करते हैं, यदि आप इस पद्धति का उपयोग करना चाहते हैं, तो SSH कुंजी बनाने और उपयोग करने में सहायता के लिए इस मार्गदर्शिका को देखें।

— k107
स्रोत

52

आह, इसलिए वे HTTPS की सिफारिश करते हैं ताकि उन्हें दस्तावेज़ न करना पड़े ssh-agent? काफी उचित। धन्यवाद!

— sarnold

74

@sarnold यह शायद ssh- एजेंट और सार्वजनिक कुंजी प्रबंधन से संबंधित प्रश्नों की मात्रा के साथ अधिक है, और कॉर्पोरेट फ़ायरवॉल की संख्या जो आउटबाउंड HTTP / HTTPS की अनुमति देती है, लेकिन SSH की नहीं।

— टॉड ए। जैकब्स

7

मुझे लगता है कि https लोगों को आरंभ करने के लिए आसान बनाता है क्योंकि आपको संपूर्ण जनरेट / कॉपी / ssh कुंजी व्यवसाय करने की आवश्यकता नहीं है। साथ ही इसे गितुब के दृष्टिकोण से अधिक सुरक्षित रूप से देखा जा सकता है क्योंकि एक हमलावर जिसे आपका ssh पासवर्ड मिला है (या आपके द्वारा खुला छोड़ दिया गया कंप्यूटर टर्मिनल मिला) को अभी भी कुछ भी पुश करने के लिए आपके Github पासवर्ड को जानना होगा।

— k107

4

@kristi यदि हमलावर को पासवर्ड कैश के समाप्त होने से पहले उस टर्मिनल का पता चलता है, तो क्या वह पासवर्ड नहीं जानता है, तब भी वह धक्का नहीं दे पाएगा? प्रश्न उसी के बारे में है यदि आप ssh-Agent का उपयोग करते हैं, तो स्पष्ट अंतर यह है कि आपको अपने github पासवर्ड के बजाय ssh कुंजी का पासवर्ड दर्ज करना होगा (और कैश समाप्ति के लिए कोई स्पष्ट सेटिंग नहीं लगती है)। Ssh कुंजी पासवर्ड के बजाय github पासवर्ड दर्ज करने का विचार एक कदम पीछे की तरफ लगता है, एक छोटी सी के बाद से दो चाबियाँ आपको एक ही AFAIK के बारे में बताती हैं।

— हालील Halzgür

8

मुझे लगता है कि यह लगभग पूरी तरह से समर्थन प्रश्नों की मात्रा को कम करने के बारे में है जो उन्हें मिलते हैं। मैं तुम्हें यह भी तर्क हो सकता है कि जब से तुम लगता है अपना पासवर्ड वेबसाइट का उपयोग करने के लिए वैसे भी HTTPS पर प्रवेश करने के लिए, आप नहीं हो सकता बढ़ रही है एक अलग प्रमाणीकरण तंत्र (SSH कुंजियां) का उपयोग करके सुरक्षा, लेकिन feasibly आप हमले सतह में वृद्धि कर रहे हैं जो सुरक्षा में कमी हो सकती है। फिर भी, HTTPS और SSH दोनों को पर्याप्त रूप से सुरक्षित किया जाना चाहिए यदि इसका सही उपयोग किया जाए।

— कार्ट्रो

52

मुझे लगता है कि HTTPS कई कारणों से GitHub द्वारा अनुशंसित है

1) यह कहीं से भी उपयोग करने के लिए सरल है क्योंकि आपको केवल अपने खाते के विवरण की आवश्यकता है (कोई SSH कुंजी की आवश्यकता नहीं है)

2) HTTPS एक बंदरगाह है जो सभी फायरवॉल में खुला है। SSH हमेशा बाहरी नेटवर्क के लिए संचार के लिए एक बंदरगाह के रूप में खुला नहीं होता है

इसलिए GHHH रिपॉजिटरी SSH की तुलना में HTTPS का उपयोग करके अधिक सार्वभौमिक रूप से सुलभ है।

मेरे विचार में SSH कुंजियाँ उन्हें बनाने में छोटे अतिरिक्त काम के लायक हैं

1) SSH कुंजी आपके GitHub खाते तक पहुँच प्रदान नहीं करती है, इसलिए यदि आपका खाता चोरी हो गया है, तो आपका खाता अपहृत नहीं किया जा सकता है,

2) अपने SSH कुंजी के साथ एक मजबूत keyphrase का उपयोग किसी भी दुरुपयोग को सीमित करता है, भले ही आपकी कुंजी चोरी हो जाए

यदि आपका GitHub खाता क्रेडेंशियल (उपयोगकर्ता नाम / पासवर्ड) चोरी हो गया है, तो आपका GitHub पासवर्ड आपको एक्सेस से ब्लॉक करने के लिए बदला जा सकता है और आपके सभी साझा किए गए रिपॉजिटरी को जल्दी से हटाया जा सकता है।

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

मेरी प्राथमिकता SSH को पासफ़्रेज़ संरक्षित कुंजी के साथ उपयोग करना है। मेरे पास प्रत्येक कंप्यूटर के लिए एक अलग SSH कुंजी है, इसलिए यदि वह मशीन चोरी हो जाती है या चाबी से समझौता हो जाता है, तो मैं जल्दी से GitHub में लॉगिन कर सकता हूं और अवांछित पहुंच को रोकने के लिए उस कुंजी को हटा सकता हूं।

यदि आप SSH पोर्ट को ब्लॉक कर रहे हैं, तो SSH को HTTPS पर टनल किया जा सकता है।

https://help.github.com/articles/using-ssh-over-the-https-port/

यदि आप HTTPS का उपयोग करते हैं, तो मैं आपके खाते के साथ-साथ आपके भंडार की सुरक्षा के लिए दो-कारक प्रमाणीकरण जोड़ने की सलाह दूंगा।

यदि आप HTTPS का उपयोग किसी टूल (उदाहरण के लिए संपादक) के साथ करते हैं, तो आपको उस टूल कॉन्फ़िगरेशन में कैश उपयोगकर्ता नाम और पासवर्ड के बजाय अपने GitHub खाते से एक डेवलपर टोकन का उपयोग करना चाहिए।

— jr0cket
स्रोत

3

"हालांकि अगर कोई आपकी निजी कुंजी पकड़ लेता है तो वे एक खाली भंडार का एक बल धक्का कर सकते हैं और आपके परिवर्तन इतिहास को मिटा सकते हैं" - हाँ (और भयानक होगा), लेकिन वितरित कोडबेस की सुंदरता हमें किसी ऐसे व्यक्ति के साथ ठीक होने की अनुमति देती है जो इसकी एक प्रति कम से कम है।

— कैमरून

मुझे यकीन नहीं हो रहा है कि कोई जबरदस्ती धक्का देने में सक्षम है, SSH और HTTPS के बीच अंतर है। अगर आपके पास आपका उपयोगकर्ता नाम और पासवर्ड होता है, तो मैं समान रूप से जोर लगा सकता हूं।

— मैट कैंटी

यदि आपके पास उपयोगकर्ता नाम और पासवर्ड है, तो आप सब कुछ हटा सकते हैं (पासवर्ड और ईमेल संपर्क बदलने के बाद)। प्रत्येक रिपॉजिटरी पर व्यक्तिगत बल पुश करने की आवश्यकता नहीं है यदि आप उन्हें हटा सकते हैं।

— jr0cket

आप पासवर्ड बनाम ssh कुंजी की तुलना कर रहे हैं, जबकि https कनेक्शन के लिए एक विशेष टोकन की आवश्यकता होती है।

— एलेक्सी श्री।

13

या तो आप गलत उद्धृत कर रहे हैं या अलग-अलग पेजों पर गीथूब की अलग-अलग सिफारिश है या वे समय के साथ सीख सकते हैं और अपने रीको को अपडेट कर सकते हैं।

GitHub के साथ बातचीत करते समय हम SSH कनेक्शन का उपयोग करने की दृढ़ता से सलाह देते हैं। SSH चाबियाँ पासवर्ड को शामिल किए बिना, विश्वसनीय कंप्यूटर की पहचान करने का एक तरीका है। नीचे दिए गए चरण आपको SSH कुंजी जनरेट करके और फिर आपके GitHub खाते में सार्वजनिक कुंजी जोड़कर चलेंगे।

https://help.github.com/articles/generating-ssh-keys

— सरस्वती को सिड
स्रोत

22

FWIW, इस पृष्ठ में अब इस उत्तर में उद्धृत "दृढ़ता से अनुशंसा" पाठ शामिल नहीं है।

— स्कॉट आइजकस

निम्न लिंक में HTTPS के लिए अभी भी "अनुशंसित" का उपयोग करें: help.github.com/articles/which-remote-url-should-i-use/… "HTTPS URL के साथ क्लोनिंग (अनुशंसित)"

— JBE

10

यदि यह फ़ायरवॉल द्वारा अवरुद्ध है, तो HTTPS पर SSH कनेक्शन को सक्षम करना

परीक्षण करें कि HTTPS पोर्ट पर SSH संभव है, तो इस SSH कमांड को चलाएं:

$ ssh -T -p 443 git@ssh.github.com
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

अगर वह काम किया, बहुत अच्छा! यदि नहीं, तो आपको हमारे समस्या निवारण गाइड का पालन करने की आवश्यकता हो सकती है ।

यदि आप SSH को git@ssh.github.comपोर्ट 443 से अधिक में सक्षम हैं , तो आप उस सर्वर और पोर्ट को चलाने के लिए GitHub के किसी भी कनेक्शन को बाध्य करने के लिए अपनी SSH सेटिंग्स को ओवरराइड कर सकते हैं।

इसे अपने ssh कॉन्फ़िगर में सेट करने के लिए, फ़ाइल को यहाँ संपादित करें ~/.ssh/configऔर इस सेक्शन को जोड़ें:

Host github.com
  Hostname ssh.github.com
  Port 443

आप परीक्षण कर सकते हैं कि यह एक बार GitHub से जुड़कर काम करता है:

$ ssh -T git@github.com
Hi username! You've successfully authenticated, but GitHub does not
provide shell access.

से प्रमाणित कर रहा है GitHub के लिए / HTTPS पोर्ट पर SSH का उपयोग करना

— MJA
स्रोत

9

यह भी देखें: मुझे कौन सा रिमोट URL इस्तेमाल करना चाहिए? help.github.com पर जवाब दें।

संपादित करें:

ऐसा लगता है कि SSH URL का उपयोग करने के लिए सार्वजनिक रेपो तक पहुँच लिखना आवश्यक नहीं है, मेरे मूल विवरण को अमान्य करार दिया गया है।

मूल:

जाहिर है HTTPS URL का पक्ष लेने का मुख्य कारण यह है कि SSH URL एक सार्वजनिक रेपो के साथ काम नहीं करेगा यदि आपके पास उस रेपो तक लिखने की सुविधा नहीं है।

SSH URL के उपयोग को उत्पादन सर्वर पर तैनाती के लिए प्रोत्साहित किया जाता है, हालांकि - संभवतः संदर्भ यहां हरकोक जैसी सेवाएं हैं।

— मार्क टाई
स्रोत

1

"ये URL SSH पर एक git रिपॉजिटरी तक पहुँच प्रदान करते हैं। इन URL का उपयोग करने के लिए, आपके पास एक सार्वजनिक रिपॉजिटरी या किसी निजी रिपॉजिटरी तक किसी भी एक्सेस के लिए लिखना होगा। ये URL एक पब्लिक रिपॉजिटरी के साथ काम नहीं करेंगे जिनके पास लिखने की एक्सेस नहीं है। " - यह सच नहीं है। कोई भी एक SSH url के साथ एक सार्वजनिक रेपो पर क्लोन कर सकता है, जिसमें उनकी पहुंच नहीं है

— Sam

1

@Sam यह अब सच नहीं हो सकता है, लेकिन जब मैंने सवाल का जवाब दिया तो यह सच था। मैंने परिवर्तन को प्रतिबिंबित करने के लिए अपना उत्तर संपादित किया है।

— मार्क तिये

वास्तव में। प्रश्न "कैसे GHHHH SSH पर HTTPS की सिफारिश करता है" निरर्थक होगा।

— मार्क टाई

0

यह तर्क करना संभव है कि प्रमाणित करने के लिए SSHs कुंजी का उपयोग करना कम सुरक्षित है क्योंकि हम नए SSH कुंजी उत्पन्न करने की तुलना में समय-समय पर अपना पासवर्ड बदलते रहते हैं।

वे सर्वर जो जीवनकाल को सीमित करते हैं, जिसके लिए वे SSH कुंजियों का सम्मान करेंगे, उपयोगकर्ताओं को एसएसएच-की-रिफ्रेशिंग के अभ्यास के लिए मजबूर कर सकते हैं।

— benhorgen
स्रोत

अब उपयोगकर्ताओं को समय-समय पर अपने पासवर्ड बदलने की सलाह देना बुरा माना जाता है। ब्रिटेन की सरकारें देखें: ncsc.gov.uk/articles/problems-forcing- अनियमित-password

— expiry

-3

हो सकता है क्योंकि आपके मस्तिष्क से पासवर्ड चोरी करना कठिन है, तो आपके कंप्यूटर से एक महत्वपूर्ण फ़ाइल चोरी करना (कम से कम मेरे ज्ञान में, शायद कुछ पदार्थ पहले से ही मौजूद हैं या विधियां हैं लेकिन यह एक अनंत चर्चा है)? और यदि आप पासवर्ड कुंजी की रक्षा करते हैं, तो आप फिर से एक पासवर्ड का उपयोग कर रहे हैं और वही समस्याएं उत्पन्न होती हैं (लेकिन कुछ का तर्क हो सकता है कि आपको अधिक काम करना होगा, क्योंकि आपको कुंजी प्राप्त करने और फिर पासवर्ड को क्रैक करने की आवश्यकता है)।

— तादेज
स्रोत

GitHub SSH पर HTTPS की सिफारिश क्यों करता है?

यदि यह फ़ायरवॉल द्वारा अवरुद्ध है, तो HTTPS पर SSH कनेक्शन को सक्षम करना