46

मेरे पास एक सर्वर है जिसे मुझे ssh के माध्यम से अक्सर एक्सेस करना पड़ता है, क्योंकि मैं इस पर गणना करता हूं। अब, कंप्यूटिंग केंद्र स्पष्ट रूप से SSH- कुंजी को मना करता है क्योंकि वे "असुरक्षित" हैं। उन्हें लगता है कि कीबोर्ड पर मेरा पासवर्ड टाइप करना, हर समय, अन्य मनुष्यों के सामने संभव है, लॉगिन करने का एक बहुत सुरक्षित तरीका है।

अभी; मैं उनके विचार नहीं बदल सकता (मैंने कोशिश की)।

क्या कम से कम अस्थाई रूप से SSH पासवर्ड स्टोर करने का एक तरीका है, GIT पासवर्ड को कुछ निर्धारित समय के लिए कैश में स्टोर कर सकता है?

ssh git

— user2667180
स्रोत

55

the computing center explicitly forbids SSH-keys because they are "insecure"- मामले पर मेरी राय? एक नया सर्वर होस्ट खोजें, क्योंकि आपका स्पष्ट रूप से अयोग्य है।

— मैट क्लार्क

18

@ मैट: "कंप्यूटिंग सेंटर" एक अकादमिक ग्रिड प्रणाली की तरह लगता है, जिसमें लगभग उतना प्रतिस्पर्धा नहीं है जितना मुझे लगता है

— ग्रेविटी

27

वे गलत हैं। जब वे खाते समाप्त करते हैं, तो वे ssh कुंजियों को निष्क्रिय करना भूल जाते हैं, इसलिए उन्होंने निर्णय लिया कि ssh कुंजियाँ समस्या हैं।

— जोशुआ

10

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

— user2667180

7

@ TheHansinator यदि वहाँ एक keylogger स्थापित है, तो आप पहले से ही उस बिंदु से समझौता कर चुके हैं जहाँ यह अब मायने नहीं रखता कि आप अपने ssh कनेक्शन की सुरक्षा कर रहे हैं या नहीं। लेकिन publickeyप्रमाणीकरण के अन्य फायदे भी हैं । यदि आप passwordसर्वर पर प्रमाणीकरण अक्षम करते हैं, तो आप उन सभी हमलावरों को पासवर्ड का अनुमान लगाने से रोकते हैं। और अगर कोई हमलावर एक क्लाइंट के खिलाफ मितम हमले का प्रयास करता है, जो पहले सर्वर की सार्वजनिक कुंजी संग्रहीत नहीं करता है, publickeyतो आप passwordप्रमाणीकरण का उपयोग करने की तुलना में बहुत बेहतर तरीके से सुरक्षित हैं ।

— कसपर

63

कनेक्शन का पुन: उपयोग

SSHv2 एक ही प्रमाणीकृत कनेक्शन को कई 'चैनल' स्थापित करने की अनुमति देता है - इंटरैक्टिव शेल, बैच कमांड, SFTP, जैसे कि एजेंट-फ़ॉरवर्डिंग या टीसीपी-फ़ॉरवर्डिंग जैसे द्वितीयक। आपका सर्वर संभवतः डिफ़ॉल्ट रूप से कनेक्शन मल्टीप्लेक्सिंग का समर्थन करता है। (यदि आपके व्यवस्थापक शिकायत करते हैं, तो यह आपके पासवर्ड को कहीं भी कैशिंग नहीं कर रहा है - यह पूरे कनेक्शन को कैशिंग कर रहा है।)

OpenSSH के साथ आपके पास ControlMasterऔर ControlPathविकल्प (-M और -S) इसका उपयोग करने के लिए हैं:

उपयोग कर एक 'मास्टर' SSH कनेक्शन शुरू करें -M। (चूँकि आपके पास अभी तक अपने विन्यास में एक ControlPath नहीं है, इसलिए आपको इसका उपयोग करके कमांड लाइन में निर्दिष्ट करने की आवश्यकता है -S। इसे लंबे समय तक रहने की आवश्यकता है, इसलिए मैं -fNपृष्ठभूमि को छोड़ने के लिए विकल्प जोड़ता हूं ; वे तकनीकी रूप से वैकल्पिक हैं अन्यथा।)
```
$ ssh foo@bar.example.com -fNMS ~/.ssh/bar.socket
foo@bar.example.com's password:
```
आप स्थानीय शेल पर वापस आ गए हैं।
मास्टर के माध्यम से एक नया कनेक्शन शुरू करें:
```
$ ssh foo@bar.example.com -S ~/.ssh/bar.socket
```
आप अंदर हैं।
Git / rsync / SFTP के लिए इसे उपयोगी बनाने के लिए, आपको ControlPathअपने कॉन्फ़िगरेशन में सेट अप करने की आवश्यकता है , क्योंकि आप -Sहर समय निर्दिष्ट नहीं कर पाएंगे :
```
Host *
    ControlPath ~/.ssh/S.%r@%h:%p
```

आप इसे स्वचालित कर सकते हैं - हाल ही में ओपनएसएसएच संस्करणों में भी ControlPersistस्वचालित रूप से पृष्ठभूमि में एक मास्टर कनेक्शन स्थापित होता है अगर अभी तक कोई नहीं है। इससे आप चरण 1 को छोड़ सकते हैं और सामान्य रूप से जैसा आप चाहते हैं, वैसे ही ssh का उपयोग करें ।

में विन्यास ~/.ssh/config:

Host *
    ControlPath ~/.ssh/S.%r@%h:%p
    ControlMaster auto
    ControlPersist 15m

पहला कनेक्शन पासवर्ड मांगता है:
```
$ ssh foo@bar.example.com
foo@bar.example.com's password:
[foo@bar:~]$ exit
```

दूसरा नहीं है:

$ ssh foo@bar.example.com
[foo@bar:~]$ yay

मल्टीप्लेक्स मास्टर को नियंत्रित करने के लिए (इसे बंद करें या टीसीपी अग्रेषण कॉन्फ़िगर करें), -Oविकल्प का उपयोग करें ।

इसी तरह की विधि हाल के पुटी संस्करणों द्वारा समर्थित है ।

— grawity
स्रोत

1

इस अच्छे उत्तर के लिए बहुत-बहुत धन्यवाद। इस समस्या पर Google उपयोगी नहीं था, क्योंकि यह हमेशा ssh-keys में बदल जाता था और मुझे सही कीवर्ड नहीं पता थे। मेरी बहुत मदद की!

— user2667180

1

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

— शेल्टर

3

@ शेलेस्टर: आपका मतलब है "एक ही यूआईडी वाला", जैसा कि पहले से ही एसश-एजेंट के साथ है। यहां तक कि अगर आप जानबूझकर सॉकेट फ़ाइल की अनुमतियों को खोलते हैं (जो कि डिफ़ॉल्ट रूप से 0600 हैं), अन्य उपयोगकर्ता इसे से केवल "मल्टीप्लेक्स यूआईडी बेमेल" प्राप्त करेंगे।

— ग्रेविटी

3

@shellster रूट वाला कोई भी एक कीगलर स्थापित कर सकता है और आपके पासवर्ड को दूरस्थ सिस्टम में वैसे भी चोरी कर सकता है, या किसी भी प्रकार की नापाक बातें कर सकता है। यदि हम स्थानीय रूट के बारे में चिंतित हैं, तो यह SSH निजी कुंजी को सहेजने से कम सुरक्षित नहीं है।

— अमलॉयल

1

मैं स्थानीय रूट को खतरा नहीं मानता क्योंकि अगर यह कभी खतरा बन जाता है, तो आप कोई फर्क नहीं पड़ता। (जैसा कि सरकार-ग्रेड जासूसी के साथ।) स्पष्ट रूप से एक स्थानीय रूट आपके ssh क्लाइंट और ssh- एजेंट को जो कुछ भी चाहते हैं, बदल सकता है। /Root/.secret में सभी पासवर्ड और निजी कुंजियाँ संग्रहीत करें? ज़रूर।

— ग्रेविटी

19

उपयोग `sshpass`

sshpass ( github , मैन पेज ) एक उपकरण है जो स्वचालित रूप से ssh को पासवर्ड फीड करता है। इसका उपयोग करने का सुरक्षित तरीका यह है:

% echo 'correct horse battery staple' > ~/.ssh/compute_password
% chmod go-rw ~/.ssh/compute_password

% sshpass -f ~/.ssh/compute_password ssh foo@host

यह ~/.ssh/compute_passwordपासफ़्रेज़ के बिना एक निजी कुंजी फ़ाइल की तरह पासवर्ड को पढ़ेगा । आप sshpassउस पूरी कमांड को टाइप करने से बचने के लिए कमांड को एक छोटे शेल स्क्रिप्ट या शेल एलियास में रख सकते हैं । अफसोस की बात है कि मुझे ऐसा करने का कोई तरीका नहीं मिला ~/.ssh/config।

(कमांड लाइन पर सीधे पासवर्ड निर्दिष्ट करना भी संभव है sshpass, लेकिन इससे बचा जाना चाहिए, क्योंकि यह पासवर्ड को किसी को भी लीक करता है जो कर सकता है ps)

अन्य तरीकों से तुलना

यह दृष्टिकोण निश्चित रूप से सार्वजनिक कुंजी प्रमाणीकरण को ठीक से स्थापित करने की तुलना में कम सुरक्षित है, लेकिन आप शायद पहले से ही जानते हैं।

कनेक्शन पुन: उपयोग के बारे में @ ग्रेविटी के उत्तर की तुलना में यह कम सुरक्षित है, लेकिन इसका लाभ यह है कि पासवर्ड को अंतःक्रियात्मक रूप से दर्ज नहीं करना है।

आप @ gravity के उत्तर को पासफ़्रेज़ और निजी कुंजी कैशिंग (यानी ssh-agent) के साथ पबकी के विकल्प का विकल्प मान सकते हैं । फिर मेरा जवाब निजी कुंजी फ़ाइल पर पासफ़्रेज़ के बिना पबकी स्थिति के लिए एक विकल्प होगा।

— marcelm
स्रोत

3

अगर कंप्यूटिंग सेंटर्स की नीति "लेकिन केपेयर डिस्क पर संग्रहीत की जाती है, जहां कोई उन्हें चोरी कर सकता है" के आधार पर लिखा गया था, तो ऐसा लगता है कि नीति बल्कि बैकफ़ायर करने जा रही है।

— grawity

6

@ अच्छी स्थिति, खराब नीतियों के कारण और भी बुरे काम होते हैं। s \ _ (

— ity

1

यदि आप अपने पासवर्ड को यादृच्छिक वर्णों की एक लंबी लंबी धारा ( head -c 16 /dev/urandom | base64128 बिट्स के लिए कहें ) के रूप में उत्पन्न करते हैं और अन्य प्रणालियों पर इसका उपयोग नहीं करते हैं, तो यह सुरक्षा-कुंजी के समान है। यदि फोर्स करने के लिए कठिन ब्रूट के रूप में, और फ़ाइल से उपयोग करने के लिए सरल है अगर एन्क्रिप्ट नहीं किया गया है। यह बुरे आदमी के लिए भी जाता है, अगर उन्हें फ़ाइल मिलती है। अंतर केवल इतना है कि पासवर्ड सर्वर पर भेजा जाता है, जबकि कुंजी में यह साबित करने के लिए कि आपके पास सही निजी कुंजी है, और प्रयोज्य-वार के पास यह साबित करने के लिए बेहतर गणित है, पासवर्ड युक्त फाइल को एन्क्रिप्ट करना कठिन है (नहीं मानक उपकरण)।

— लक्कू

1

पासवर्ड मैनेजर का उपयोग करें।

कुछ पासवर्ड मैनेजर (उदा। KeePassXC) में 'ऑटो-टाइप' फीचर होता है। आप पासवर्ड को पासवर्ड मैनेजर पर स्टोर करते हैं, जब आप मैनेजर चलाते हैं तो डेटाबेस को अनलॉक करते हैं और हर बार जब आप sshअपने पासवर्ड के लिए संकेत देते हैं तो आप एक कुंजी संयोजन दबाते हैं जिससे पासवर्ड मैनेजर कंसोल पर आपका लंबा पासवर्ड लिख देता है।

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

आप इस सूची से अपना पसंदीदा चुन सकते हैं: https://en.wikipedia.org/wiki/List_of_password_managers

— स्टायरोफोम मक्खी
स्रोत

3

मुझे यकीन नहीं है कि टर्मिनल-आधारित कार्यक्रमों के साथ ऑटो-प्रकार की सुविधा अच्छी तरह से काम करती है। पता लगाने के लिए एक विशिष्ट विंडो शीर्षक की तलाश होगी, और आत्मकेंद्रित ही सबसे अच्छा नहीं फैंसी "विरोधी keylog" सुविधाओं है कि KeePass2 था ...

— grawity

1

@ ग्रेविटी ने gnome-terminalअपना शीर्षक ssh somehostतब बदला जब ssh ने मुझसे पासवर्ड मांगा ताकि आप बिना किसी समस्या के इसके साथ शीर्षक विंडो का मिलान कर सकें। मुझे 'एंटी-कीलॉगिंग' सुविधाओं के बारे में कुछ भी पता नहीं है - मैं दैनिक आधार पर टर्मिनल में KeePassXC का उपयोग कर रहा हूं और सबसे खराब स्थिति से निपटने के लिए मुझे सूची से उपयुक्त खाता चुनना है।

— स्टायरोफोम

2

@grawity एंटी-कीलॉगिंग सुविधाओं को वैसे भी प्रति-प्रविष्टि के आधार पर सक्षम करने की आवश्यकता होती है (वास्तव में इस कारण से कि कई प्रोग्राम पेस्ट का समर्थन नहीं करते हैं)।

— बॉब

0

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

एक और वास्तव में अच्छा ग्राहक टर्मियस है । यह न केवल विंडोज और लिनक्स बल्कि ओएसएक्स, आईओएस और एंड्रॉइड को भी सपोर्ट करता है। हालाँकि यह मुख्य रूप से फोन के लिए डिज़ाइन किया गया था लेकिन डेस्कटॉप संस्करण वास्तव में काफी अच्छा है।

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

सभी GUI क्लाइंट में कनेक्शन सेटिंग्स सहेजने की क्षमता शामिल होती है जिसमें आपका उपयोगकर्ता नाम और पासवर्ड शामिल होता है।

— slebetman
स्रोत

2

"जीयूआई-आधारित" का अर्थ यह नहीं है कि यह आपके पासवर्ड को संग्रहीत करने की अनुमति देगा, ऐसा कुछ जो पुट्टी स्पष्ट रूप से करने से इनकार करता है । विंडोज के साथ बंडल किया गया हाइपरटर्मिनल का संस्करण टेलनेट-ओनली था, जो धारावाहिक लिंक पर अधिक केंद्रित था। शायद आप विंडोज के लिए CKermit के बारे में सोच रहे हैं जिसमें SSH समर्थन है, लेकिन इसका सिफर समर्थन इतना पुराना है कि यह आसानी से कई वर्तमान सर्वरों से कनेक्ट नहीं होगा।

— grawity

यदि SSH- कुंजी निषिद्ध हैं तो पासवर्ड कैश करें

कनेक्शन का पुन: उपयोग

उपयोग sshpass

अन्य तरीकों से तुलना

उपयोग `sshpass`