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


मैं अपनी एसएसएच पहचान फाइलों को अपने ~ / .ssh / फ़ोल्डर के अंदर डाल रहा हूं। मेरे पास शायद लगभग 30 फाइलें हैं।

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

ssh -i ~ / .ssh / client1-identity client1@10.1.1.10

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

ssh user123@example.com

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

उपयोगकर्ता 123 के लिए बहुत अधिक प्रमाणीकरण विफलताओं

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

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

होस्ट example.com
पसंदीदा प्रमाणीकरण कीबोर्ड-इंटरैक्टिव, पासवर्ड

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

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


85
2018-04-09 17:01


मूल


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


जवाब:


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

इस उदाहरण में, एसएसएच होगा केवल 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= विनिमेय हैं।


78
2018-04-09 17:11



एक उदाहरण अच्छा होगा - rubo77
यह नहीं है: IdentitiesOnly yes ("=" के बिना)? - Dimitrios Mistriotis
@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
@ निक एंडरेग धन्यवाद - Dimitrios Mistriotis


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

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

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

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


74
2018-06-12 22:46



अच्छी तरह से समझाया, धन्यवाद। यह स्पष्ट नहीं है कि पैरामीटर 'पहचान केवल' का अर्थ है TakeOnlyWhatIExplicitlySpecifyThenFailoverToPassword। और जाहिर है, ./ssh/id_rsa कुंजी अभी भी सूचीबद्ध है। - lImbus
लाना IdentitiesOnly yes ssh_config के वैश्विक खंड में यह मेरे लिए क्या किया गया है। धन्यवाद! - jamix
विस्तृत टिप्पणी के लिए धन्यवाद। मैं उपयोग करता था ('\' नई लाइन के लिए) Host * \ IdentityFile ~/.ssh/mykeyकॉन्फ़िगरेशन विकल्प के रूप में, और सबसे पहले यह अजीब लग रहा था कि एक विशिष्ट साइट के लिए एक अलग प्रविष्टि है, उदा। Host special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yes आपूर्ति जारी रखा mykey के बजाय specialkey। यह निश्चित रूप से अस्पष्ट था, जब तक मुझे एहसास नहीं हुआ (आपके उत्तर से) कि पहचान फ़ील्ड प्रविष्टियों को मूल्यांकन के क्रम में रखा गया है और अंतिम परिभाषित एक का उपयोग किया जाएगा। निकाला जा रहा है IdentityFile ~/.ssh/mykey इस मुद्दे को हल किया, और सही, एकल कुंजी का उपयोग किया गया था। - Ryder
इससे पहले कि मैंने कोशिश की, मैंने देखा git pull/push आदेश मेरे एजेंट में लोड हर पहचान की कोशिश कर रहे थे। यह एक समस्या नहीं थी जब तक कि एक बिंदु पर मेरे पास बहुत सी चाबियाँ नहीं थीं। - sdkks


मैं आमतौर पर ऐसा करता हूं:

$ 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 सीएलआई के माध्यम से निजी कुंजी और यह someserver से कनेक्ट करने के लिए इसका उपयोग करता है।

विशेष रूप से ये खंड:

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).

15
2017-12-09 00:18



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


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

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

ssh -o PreferredAuthentications=password user@example.com

9
2018-06-19 14:19





पहचानफाइल का उपयोग करें लेकिन पासफ्रेज़ रीप्रोम्प्ट्स से बचने के लिए एसएसएच-एजेंट का उपयोग करना जारी रखें

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

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

  1. किसी भी इंटरैक्टिव कंसोल स्टार्टअप स्क्रिप्ट को हटाएं जो स्वचालित रूप से कुंजी लोड करता है ssh-agent

  2. जोड़ना AddKeysToAgent yes अपने ग्राहक की एसएसएच कॉन्फ़िगरेशन के लिए। यह आपको पहले कनेक्ट पर पासफ्रेज के लिए संकेत देगा, लेकिन फिर अपने एजेंट को कुंजी जोड़ें।

  3. उपयोग ssh-add -D जब आपको 'बहुत अधिक प्रमाणीकरण' त्रुटियां मिलती हैं। यह आपके एसएस-एजेंट कैश को बस 'रीसेट' (हटा देता है)। फिर उसी सत्र में फिर से कनेक्शन का प्रयास करें। आपको पासफ्रेज के लिए संकेत दिया जाएगा, और एक बार स्वीकार किया जाएगा, यह आपके एजेंट में जोड़ा जाएगा। चूंकि आपके एजेंट में केवल एक ही कुंजी होगी, इसलिए आपको कनेक्ट करने की अनुमति होगी। ssh-agent फिर भी उसी सत्र के दौरान भविष्य में कनेक्शन के लिए प्रतिकृतियों से बचने के लिए है।

    Host ex example.com
       User joe
       HostName example.com
       PreferredAuthentications publickey,password
       IdentityFile /path/to/id_rsa
       AddKeysToAgent yes
    

4
2017-09-01 20:10



Keychain में स्वीकार कुंजी स्वीकार करेंगे? - vfclists


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

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

$ SSH_AUTH_SOCK= ssh user@server

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

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused

1
2018-06-02 17:57





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

Host *
PreferredAuthentications keyboard-interactive,password

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


0
2017-08-14 22:57



इस सवाल के बारे में पूछा गया कि किस सार्वजनिक कुंजी का उपयोग किया जाता है। यह उत्तर पूरी तरह से सार्वजनिक कुंजी प्रमाणीकरण अक्षम करता है। - chrishiestand
मैंने +1 किया क्योंकि यह जवाब था कि मैं googling था, धन्यवाद @ हेनरी Grebler - matiu