मैं SSH को कैसे कॉन्फ़िगर करूं इसलिए यह सभी पहचान फ़ाइलों को स्वचालित रूप से आज़माने के लिए नहीं है?

101

मैं अपने ssh पहचान फाइलों को अपने ~ / .shsh / फ़ोल्डर के अंदर डाल रहा हूं। मेरे पास संभवतः लगभग 30 फाइलें हैं।

जब मैं सर्वर से जुड़ता हूं, तो मैं पहचान फ़ाइल का उपयोग करने के लिए निर्दिष्ट करूंगा, जैसे कुछ

ssh -i ~ / .ssh / client1-पहचान client1@10.1.1.10

हालाँकि, अगर मैं एक पहचान फ़ाइल निर्दिष्ट नहीं करता, और बस कुछ इस तरह का उपयोग करें:

ssh user123@example.com

मुझे त्रुटि मिलती है

User123 के लिए बहुत अधिक प्रमाणीकरण विफलताएँ

मैं समझता हूं कि क्योंकि यदि कोई पहचान फ़ाइल निर्दिष्ट नहीं है, और ssh पहचान फ़ाइलों को ढूँढ सकता है, तो यह उन सभी को आज़माएगा।

मैं यह भी समझता हूं कि मैं ~/.ssh/configफ़ाइल को संपादित कर सकता हूं और कुछ निर्दिष्ट कर सकता हूं :

मेजबान example.com
PreferredAuthentication कीबोर्ड-इंटरैक्टिव, पासवर्ड

उस कनेक्शन को ज्ञात पहचान फ़ाइलों को आज़माने से रोकने के लिए।

इसलिए, मुझे लगता है कि मैं अपनी पहचान फ़ाइलों को ~/.ssh/निर्देशिका के बाहर स्थानांतरित कर सकता हूं , या मैं प्रत्येक होस्ट को निर्दिष्ट कर सकता हूं जिसे मैं कॉन्फ़िगर फ़ाइल के लिए पहचान-फ़ाइल प्रमाणीकरण को अक्षम करना चाहता हूं, लेकिन क्या एसएसएच को डिफ़ॉल्ट खरीदने के लिए कोई रास्ता नहीं है? पहचान फ़ाइलें? या लोगों को यह निर्दिष्ट करने के लिए खोज करेंगे?

— CWD
स्रोत

4

पुन: "मैं समझता हूं कि ऐसा इसलिए है ..." - ssh -vसुनिश्चित करने के लिए पता लगाने के लिए उपयोग करें।

— grawity

101

आप IdentitiesOnly=yesविकल्प का उपयोग कर सकते हैं IdentityFile( ssh_config मैन पेज देखें )। इस तरह, आप यह निर्दिष्ट कर सकते हैं कि किस फ़ाइल को देखना चाहिए।

इस उदाहरण में, ssh केवल ssh_config फाइलों में दी गई पहचानों में दिखेगा + कमांड लाइन पर सूचीबद्ध 4 लोग (एजेंट द्वारा प्रदान की गई पहचान को नजरअंदाज किया जाएगा):

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    user123@example.com

रूपों -iऔर -o IdentityFile=विनिमेय हैं।

— init_js
स्रोत

7

एक उदाहरण अच्छा होगा

— rubo77

1

क्या यह नहीं है: IdentitiesOnly yes("=" के बिना)?

— दिमित्रियो मिस्ट्रिटिस

3

@DimitriosMistriotis ssh_config मैन पेज के अनुसार, या तो स्वीकार्य है:

Configuration options may be separated by whitespace or optional whitespace and exactly one '='; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp, and sftp -o option.

— Nick Anderegg

IdentitiesOnlyहमेशा काम नहीं कर सकता, आपको विशेष रूप से एक मेजबान को बाहर करना पड़ सकता है; देखें superuser.com/questions/859661/…

— aexl

79

user76528 का संक्षिप्त उत्तर सही है, लेकिन मुझे अभी यह समस्या थी और सोचा था कि कुछ विस्तार उपयोगी होगा। आप इस समाधान के बारे में भी सोच सकते हैं यदि आपको आश्चर्य हो कि "ssh मेरे आइडेंटिफ़ाइल कॉन्फ़िगरेशन विकल्प की अनदेखी क्यों कर रहा है"?

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

दूसरा, यदि आप एक ssh- एजेंट का उपयोग करते हैं, तो ssh स्वचालित रूप से एजेंट में कुंजियों का उपयोग करने का प्रयास करेगा, भले ही आपने उन्हें ssh_config के IdentityFile (या -i) विकल्प के साथ निर्दिष्ट न किया हो। यह एक सामान्य कारण है कि आपको Too many authentication failures for userत्रुटि मिल सकती है । IdentitiesOnly yesविकल्प का उपयोग करने से यह व्यवहार अक्षम हो जाएगा।

यदि आप एक से अधिक सिस्टम में एक से अधिक उपयोगकर्ता के रूप में ssh करते हैं, तो मैं आपको IdentitiesOnly yesssh_config के अपने वैश्विक अनुभाग में रखने की सलाह देता हूं, और प्रत्येक IdentityFileको उपयुक्त होस्ट सबस्क्रिप्शन के भीतर डाल देता हूं ।

— chrishiestand
स्रोत

5

अच्छी तरह से समझाया, धन्यवाद। यह स्पष्ट नहीं है कि पैरामीटर 'आइडेंटिटीऑनली' का अर्थ टेकऑनली व्हाट्सएपप्लेक्लाइस्पेक्टिफाइथेनफेलओवरटैसपासवर्ड है । और स्पष्ट रूप से, ./ssh/id_rsa कुंजी अभी भी सूचीबद्ध है।

— lImbus

IdentitiesOnly yesSsh_config के वैश्विक खंड में लाना मेरे लिए यही था। धन्यवाद!

— जामिक्स

1

विस्तृत टिप्पणी के लिए धन्यवाद। मैं (newline के लिए '\') का उपयोग करते थे Host * \ IdentityFile ~/.ssh/mykeyएक विन्यास विकल्प के रूप में, और पहली बार में यह अजीब लगा कि किसी विशिष्ट साइट, उदाहरण के लिए एक अलग प्रवेश होने लग रहा था Host special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yesकी आपूर्ति के लिए जारी रखा mykeyके बजाय specialkey। यह निश्चित रूप से अस्पष्ट था, जब तक मुझे एहसास नहीं हुआ (आपके उत्तर से) कि IdentityFile प्रविष्टियां मूल्यांकन के क्रम में खड़ी हैं और अंतिम-परिभाषित एक का उपयोग किया जाएगा। निकाला जा रहा है IdentityFile ~/.ssh/mykeyसमस्या हल हो जाती है, और सही, एकल कुंजी इस्तेमाल किया गया था।

— Ryder

1

इससे पहले कि मैं यह कोशिश करता, मैंने देखा कि मेरे git pull/pushकमांड मेरे एजेंट में भरी हुई हर एक पहचान की कोशिश कर रहे थे। यह एक समस्या नहीं थी जब तक कि मेरे पास बहुत सी चाबियाँ थीं।

— sdkks

21

मैं आम तौर पर इसे पसंद करता हूं:

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa root@server.mydom.com

विकल्प इस प्रकार हैं:

-o IdentitiesOnly=yes- एसएसएच को केवल उन कुंजियों का उपयोग करने के लिए कहता है जो सीएलआई के माध्यम से और एस $HOME/.ssh-एजेंट के माध्यम से या किसी से भी प्रदान नहीं की जाती हैं
-F /dev/null - के उपयोग को अक्षम करता है $HOME/.ssh/config
-i ~/path/to/some_id_rsa - कुंजी जिसे आप स्पष्ट रूप से कनेक्शन के लिए उपयोग करना चाहते हैं

उदाहरण

$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa root@someserver.mydom.com
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /dev/null
debug1: Connecting to someserver.mydom.com [10.128.12.124] port 22.
debug1: Connection established.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA f5:60:30:71:8c:a3:da:a3:fe:b1:6d:0b:20:87:23:e1
debug1: Host 'someserver' is known and matches the RSA host key.
debug1: Found key in /Users/sammingolelli/.ssh/known_hosts:103
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to someserver.mydom.com ([10.128.12.124]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Last login: Tue Dec  8 19:03:24 2015 from 153.65.219.15
someserver$

उपरोक्त आउटपुट में नोटिस sshजिसने केवल my_id_rsaसीएलआई के माध्यम से निजी कुंजी की पहचान की है और यह इसे सोमेसर से कनेक्ट करने के लिए उपयोग करता है।

विशेष रूप से इन वर्गों:

debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1

तथा:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

— SLM
स्रोत

1

धन्यवाद, यह एकमात्र पूर्ण समाधान है। जाहिर है, -F /dev/nullअन्य उत्तरों में लापता टुकड़ा है।

— leden

10

इस परिदृश्य में जहाँ आपके पास कई कुंजियाँ हैं, आप हमेशा "बहुत सारे प्रमाणीकरण विफलताओं" त्रुटि में चलेंगे। यदि आपके पास एक पासवर्ड है, और लॉगिन करने के लिए बस पासवर्ड का उपयोग करना चाहते हैं, तो यहां बताया गया है कि आप इसे कैसे करते हैं।

केवल पासवर्ड प्रमाणीकरण का उपयोग करने के लिए और सार्वजनिक कुंजी का उपयोग न करें, और कुछ भ्रामक "कीबोर्ड-इंटरैक्टिव" (जो पासवर्ड सहित एक सुपरसेट) का उपयोग न करें, आप इसे कमांड लाइन से कर सकते हैं:

ssh -o PreferredAuthentications=password user@example.com

— ग्रेग रंडलेट
स्रोत

7

आइडेंटिटीफाइल का इस्तेमाल करें लेकिन पासफ्रेज रिप्रोडीफ़ोर्स से बचने के लिए ssh-Agent का इस्तेमाल करते रहें

उपयोग करने के स्वीकृत उपाय का IdentitiesOnly yesअर्थ है कि आप कभी भी ssh- एजेंट का लाभ नहीं ले पाएंगे, जिसके परिणामस्वरूप आपकी कुंजी लोड करते समय आपके पासफ़्रेज़ के लिए बार-बार संकेत दिए जाते हैं।

ssh-agent'बहुत अधिक प्रमाणीकरण विफलताओं' त्रुटियों का उपयोग करने और उससे बचने के लिए, यह प्रयास करें:

किसी भी इंटरेक्टिव कंसोल स्टार्टअप स्क्रिप्ट को निकालें जो कि कीज़ को अपने आप लोड करता है ssh-agent।
जोड़ने के AddKeysToAgent yesअपने ग्राहक की ssh config करने के लिए। यह आपको पहले कनेक्ट पर पासफ़्रेज़ के लिए संकेत देगा, लेकिन फिर अपने एजेंट की कुंजी जोड़ें।
ssh-add -Dजब आपको 'बहुत अधिक प्रमाणीकरण' त्रुटियां मिलें तो उपयोग करें । यह बस आपके ssh- एजेंट कैश को 'रीसेट' (हटाता) करता है। फिर उसी सत्र के भीतर फिर से कनेक्शन का प्रयास करें। आपको पासफ़्रेज़ के लिए संकेत दिया जाएगा, और एक बार स्वीकार किए जाने के बाद, इसे आपके एजेंट में जोड़ दिया जाएगा। चूंकि आपके एजेंट में केवल एक ही कुंजी होगी, इसलिए आपको कनेक्ट करने की अनुमति होगी। ssh- एजेंट तब भी भविष्य के कनेक्शन के लिए एक ही सत्र के दौरान reprompts से बचने के लिए है।
```
Host ex example.com
   User joe
   HostName example.com
   PreferredAuthentications publickey,password
   IdentityFile /path/to/id_rsa
   AddKeysToAgent yes
```

— AndrewD
स्रोत

क्या चाबी को जोड़ने पर चाबी स्वीकार होगी?

— vfclists 13

2

Ssh क्लाइंट और ssh-agentएक यूनिक्स डोमेन सॉकेट के माध्यम से संचार कर रहा है जिसका नाम क्लाइंट को SSH_AUTH_SOCKपर्यावरण चर (इसके स्टार्टअप पर एजेंट द्वारा निर्धारित) द्वारा निर्दिष्ट किया गया है ।

इस प्रकार, एजेंट को क्वेरी करने से क्लाइंट के एक एकल आह्वान को रोकने के लिए इस चर को स्पष्ट रूप से कुछ अवैध रूप से सेट किया जा सकता है, जैसे खाली स्ट्रिंग;

$ SSH_AUTH_SOCK= ssh user@server

इस तरह एक क्लाइंट इनवॉइस एजेंट के साथ संवाद करने में विफल हो जाएगा और केवल सर्वर के लिए ~/.ssh/, या कमांड लाइन का उपयोग करके निर्दिष्ट किसी भी फाइल में उपलब्ध पहचान की पेशकश करने में सक्षम होगा -i।

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

— mikini
स्रोत

यह एक बेहतरीन जवाब है। यह सरल है और काम करता है जब आप कमांड का उपयोग कर रहे हैं जो "हुड के नीचे" एसएसएच का उपयोग करते हैं, जैसे गिट। अफ़सोस कि मैं इसे और अधिक नहीं बढ़ा सकता।

— rsuarez

1

आपके पास सभी का जवाब था (लगभग):

Host *
PreferredAuthentications keyboard-interactive,password

मेरे लिए काम किया।

— हेनरी ग्रीबलर
स्रोत

8

यह सवाल पूछा गया कि किस सार्वजनिक कुंजी का उपयोग कैसे किया जाए। यह उत्तर सार्वजनिक कुंजी प्रमाणीकरण को पूरी तरह से अक्षम कर देता है।

— वृषिशंड

1

मैं + 1 चाहता था क्योंकि यह जवाब था जिसके लिए मैं गुगली कर रहा था, धन्यवाद @ हेनरी ग्रीबलर

— मतिउ

1

~/.ssh/configगैर-कॉन्फिग सर्वर के लिए उपयोग कुंजियों को रोकने के लिए इसे फ़ाइल के अंत में जोड़ें :

Host *
IdentitiesOnly=yes

— मैक्सिम अक्रिस्टिनी
स्रोत