"Sign_and_send_pubkey: हस्ताक्षर करना विफल: एजेंट ने ऑपरेशन से इनकार कर दिया" कैसे हल करें?


110

SSH कुंजी के साथ एक नए डिजिटल महासागर की छोटी बूंद को कॉन्फ़िगर करना। जब मैं इसे चलाता हूं तो मुझे ssh-copy-idयही मिलता है:

ssh-copy-id user@012.345.67.89
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'user@012.345.67.89'"
and check to make sure that only the key(s) you wanted were added.

हालाँकि, जब मैं तब ssh करने का प्रयास करता हूँ, तो ऐसा होता है:

ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

पासवर्ड दर्ज करने के बाद, मैं बस ठीक लॉग इन हूं, लेकिन यह निश्चित रूप से पहले स्थान पर एसएसएच कुंजी बनाने के उद्देश्य को हरा देता है। मैंने ssh- एजेंट सर्वर-साइड पर एक नज़र डालने का फैसला किया और यहाँ मुझे क्या मिलेगा:

user@012.345.67.89:~# eval `ssh-agent -s`
Agent pid 5715
user@012.345.67.89:~# ssh-add -l
The agent has no identities.

उपयोगकर्ता /। ssh / अधिकृत_कीप में ssh-rsa कुंजी प्रविष्टि है, साथ ही साथ find -name "keynamehere"कुछ भी नहीं लौटाता है।

जवाबों:


195

ssh-addक्लाइंट मशीन पर चलाएँ , जो एजेंट के लिए SSH कुंजी जोड़ देगा।

ssh-add -l(ग्राहक पर फिर से) की पुष्टि करें कि यह वास्तव में जोड़ा गया था।


7
geez, इसे ठीक करने की कोशिश में दो घंटे बिताए और यह सब था! फिक्स्ड बिटकॉइन और एसीसीया एसएन कनेक्शन
रॉनी

18
यह पूरी तरह से यहाँ ठीक नहीं किया क्योंकि मैं gpg-agentSSH कार्यक्षमता के लिए उपयोग करता हूँ । मैं पहले से ही एक है enable-ssh-supportमें gpg-agent.confलेकिन अब भी वही त्रुटि। मैंने इसे चलाने के लिए मेलिंग सूची पर पाया है gpg-connect-agent updatestartuptty /bye:: bugs.debian.org/cgi-bin/bugreport.cgi?bug=835394
रोलैंड

1
मुझे सिर्फ gpg-agent को मारना था और फिर इसे फिर से चलाना था।
सबिन

3
जब आप एक नई SSH कुंजी उत्पन्न करते हैं, तो आपको नई निजी कुंजी (per linux.die.net/man/1/ssh-agent ) से अवगत होने के ssh-addलिए आमंत्रित किया जाना चाहिए । ssh-agent
एलेक्स

उत्कृष्ट! मैंने अपनी SSH कुंजी को फिर से बनाया है और यह होने लगा है। इसके बाद ssh-addकाम किया! धन्यवाद।
hbobenicio

65

फेडोरा 26 से 28 को अपग्रेड करने के बाद मैंने उसी मुद्दे का सामना किया। और निम्नलिखित लॉग गायब थे

/var/log/secure
/var/log/messages

मुद्दा:

antop@localmachine  ~  ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:

त्रुटि संदेश वास्तविक समस्या को इंगित नहीं कर रहा है। द्वारा हल किया गया मुद्दा

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*

मेरे .ssh/पास आवश्यक अनुमति नहीं थी क्योंकि मैंने इसे स्वयं बनाया था।
ब्रेंट बर्नबर्न

1
ऐसा लगता है कि कुछ संस्करण आपकी कुंजियों को अन्य उपयोगकर्ताओं के लिए दृश्यमान नहीं होने देते हैं। धन्यवाद!
एलन ओलाघन

यदि .ssh / * फाइलें एक ही उपयोगकर्ता द्वारा बनाई जाती हैं (रूट नहीं) तो हमें चिंता करने की जरूरत नहीं है क्योंकि इसके लिए आवश्यक अनुमति होगी।
एंटो

1
मुझे आपकी सराहना करनी चाहिए। मुझे अभी इस समस्या का सामना करना पड़ा। अपनी विधि का उपयोग करके इसे हल किया।
भूमि

55

मुझे लिनक्स उबंटू 18 में यही समस्या थी । Ubuntu 17.10 से अपडेट के बाद , हर git कमांड उस संदेश को दिखाएगा।

इसे हल करने रास्ता यकीन है कि तुम पर सही अनुमति ले ली है करने के लिए है id_rsaऔर id_rsa.pub

का उपयोग करके वर्तमान chmod संख्या की जाँच करें stat --format '%a' <file>। यह 600 के लिए id_rsa और 644 के लिए होना चाहिए id_rsa.pub

फ़ाइलों के उपयोग पर अनुमति बदलने के लिए

chmod 600 id_rsa
chmod 644 id_rsa.pub

इसने अद्यतन के साथ मेरी समस्या हल कर दी।


3
मैंने 16.04 एलटीएस से 18.04 एलटीएस से उबंटू प्रवास करने के बाद इस समस्या का सामना किया, इस समाधान ने मेरे लिए काम किया।
मुनीश चंदेल

यहाँ ही, Ubuntu को 18.04 में अपडेट करने के बाद मुझे इस समस्या का सामना करना पड़ा। यह समाधान इसे ठीक करता है।
कार्टूको सेप

id_rsa.pubक्लाइंट प्रमाणीकरण प्रक्रिया में कब उपयोग किया जाता है?
दिमित्री कोपरीवा

यदि आपके पास कई चाबियां हैं, तो आपको कुछ इस तरह का उपयोग करना चाहिए ~/.ssh:chmod 600 id_*
जीवनकाल

10

इस समस्या को हल करने के लिए नीचे दिया गया आदेश चलाएँ।

इसने मेरे लिए काम किया।

chmod 600 ~/.ssh/id_rsa

5

मेरे ssh- एजेंट के रूप में gpg- एजेंट का उपयोग करते समय और मेरी ssh कुंजी https://wiki.archlinux.org/index.php/GnuPG#gpg-agent के रूप में gpg- उपकुंजी का उपयोग करते समय मुझे त्रुटि हुई थी ।

मुझे संदेह है कि मेरी नींद + लॉक कमांड के कारण अमान्य पिन प्रविष्टि tty होने के कारण समस्या आई थी।

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"

या सिर्फ नींद / सस्पेंड

समस्या को ठीक करने के लिए पिन प्रविष्टि tty रीसेट करें

gpg-connect-agent updatestartuptty /bye > /dev/null

और मेरे बोलबाला नींद + ताला कमान के लिए तय:

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"


1
धन्यवाद। मुझे कुछ दिनों पहले यह समस्या थी, मैं आपके अनुसार gpg का उपयोग करता हूं और gpg-connect-agent updaterstartuptty /bye > /dev/nullमेरी ~ / .zshrc पर टिप्पणी की है , इस लाइन को अनसुना करने से मेरी समस्या हल हो गई।
J.Adler

4

इस त्रुटि के लिए:

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
git@github.com: Permission denied (publickey).    
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Github खाता> प्रोफ़ाइल> ssh में सार्वजनिक कुंजी फिर से सत्यापित या जोड़ें।

मैंने इस तरह हल किया:

# chmod 400 ~/.ssh/id_rsa

# ls  ~/.ssh/id_rsa -ls  
4 -r--------. 1 reinaldo reinaldo 1679 Jul 26  2017 /home/reinaldo/.ssh/id_rsa

# git pull                                 
remote: Counting objects: 35, done.
remote: Compressing objects: 100% (19/19), done.
remote: Total 35 (delta 9), reused 34 (delta 9), pack-reused 0
Unpacking objects: 100% (35/35), done.

धन्यवाद।


2

SSH त्रुटि प्राप्त करने के विभिन्न कारण हो सकते हैं:

sign_and_send_pubkey: हस्ताक्षर विफल: एजेंट ने ऑपरेशन से इनकार कर दिया

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

मेरे मामले में मुझे निम्नलिखित त्रुटि संदेश मिला है:

sign_and_send_pubkey: हस्ताक्षर विफल: एजेंट ने ऑपरेशन से इनकार कर दिया

user@website.domain.com: अनुमति अस्वीकृत (publickey, gssapi-keyex, gssapi-with-mic)

वास्तविक समस्या को खोजने का एकमात्र तरीका था -v वर्बोज़ विकल्प को लागू करना, जिसके परिणामस्वरूप बहुत सी डिबगिंग जानकारी प्रिंट की गई:

debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1

कृपया ध्यान दें कि कहने वाली रेखा key_load_public: No such file or directoryअगली पंक्ति का उल्लेख कर रही है, न कि पिछली पंक्ति का।

तो एसएसएच वास्तव में क्या कहता है कि उसे नाम की सार्वजनिक कुंजी फ़ाइल नहीं मिली है id_rsa.website.domain.com-certऔर ऐसा लगता है कि मेरे मामले में समस्या थी क्योंकि मेरी सार्वजनिक कुंजी फ़ाइल में -certप्रत्यय नहीं था ।

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

लब्बोलुआब यह है कि SSH VERBOSE MODE (-v विकल्प) का उपयोग यह पता लगाने के लिए कि क्या गलत है, इसके विभिन्न कारण हो सकते हैं, कोई भी ऐसा नहीं है जो इस / एक और सूत्र पर पाया जा सकता है।


0

यह बल्कि सुपरयूजर प्रश्न होना चाहिए।

राइट मैं MacOSX SourceTree के अंदर एक ही त्रुटि है, हालांकि, एक iTerm2 टर्मिनल के अंदर, चीजें सिर्फ बांका काम करती हैं।

हालाँकि, समस्या यह लग रही थी कि मुझे दो ssh-agent एस चल रहे हैं;

पहले जा रहा /usr/bin/ssh-agent(उर्फ मैकओएसएक्स का) और फिर होमब्रीयू भी /usr/local/bin/ssh-agentचल रहा है।

SourceTree से एक टर्मिनल ऊपर फायरिंग, मुझे में मतभेद देखने की अनुमति दी SSH_AUTH_SOCK, का उपयोग करते हुए lsofमैं दो अलग अलग पाया ssh-agentऔर फिर मैं कुंजियों (का उपयोग कर लोड करने में सक्षम था ssh-add) सिस्टम डिफ़ॉल्ट में ssh-agent(यानी। /usr/bin/ssh-agent), SourceTree फिर से काम कर रहा था।



0

मेरे लिए समस्या गीतालाब में सार्वजनिक कुंजी की एक गलत प्रतिलिपि / पेस्ट थी। प्रतिलिपि ने अतिरिक्त रिटर्न जेनरेट किया। सुनिश्चित करें कि आप जो पेस्ट करते हैं वह एक-पंक्ति कुंजी है।


0

मुझे एक sign_and_send_pubkey: signing failed: agent refused operationत्रुटि भी मिली । लेकिन मेरे मामले में समस्या एक गलत pinentryरास्ता था।

मेरे में संपत्ति एक पुराने pinentry पथ की ओर इशारा करते था। वहां के रास्ते को ठीक करना और मेरे लिए यह तय करना फिर से शुरू करना।${HOME}/.gnupg/gpg-agent.confpinentry-programgpg-agent

मैंने इसके साथ लॉग का अनुसरण करके इसकी खोज की journalctl -f। जहां गलत लाइनों वाले निम्नलिखित लॉग लाइनें हैं:

Jul 02 08:37:50 my-host gpg-agent[12677]: ssh sign request failed: No pinentry <GPG Agent>
Jul 02 08:37:57 my-host gpg-agent[12677]: can't connect to the PIN entry module '/usr/local/bin/pinentry': IPC connect call failed

0

मुझे साझा करने की आवश्यकता है, क्योंकि मैंने एक समाधान की तलाश में बहुत समय बिताया है

यहाँ समाधान था: https://unix.stackexchange.com/a/351742/215375

मैं इस कमांड का उपयोग कर रहा था:

ssh-keygen -o -t rsa -b 4096 -C "email@example.com"

सूक्ति-कीरिंग उत्पन्न कुंजी का समर्थन नहीं करता है।

-oतर्क को हटाने से समस्या हल हो गई।


0

मेरे मामले में समस्या यह थी कि GNOME कीरिंग ssh कुंजी का उपयोग करने के लिए एक अमान्य पासफ़्रेज़ पकड़ रही थी। इस समस्या का निवारण करने में मैंने जितना समय व्यतीत किया, उतने समय के बाद मुझे seahorseखाली स्ट्रिंग रखने की प्रविष्टि मिली। मैं केवल यह अनुमान लगा सकता हूं कि यह पहले कुछ समय पहले पासफ़्रेज़ को गलत तरीके से समझने के कारण हुआ था, और फिर कमांड लाइन पर वापस आने के लिए आवश्यक रूप से या तो आवश्यक रूप से रद्द कर दिया गया था। सही पासफ़्रेज़ के साथ प्रविष्टि को अपडेट करने से समस्या का तुरंत हल हो गया। उस प्रविष्टि को हटाना ("लॉगिन" कीरिंग से) और उस पहले प्रॉम्प्ट पर पासफ़्रेज़ को फिर से दर्ज करना (और उपयुक्त चेकबॉक्स की जाँच करना) इसे भी हल करता है। अब एजेंट "लॉगिन" नाम के लॉगिन कीरिंग में अनलॉक किए गए से सही पासफ़्रेज़ प्राप्त करता है और न ही पासफ़्रेज़ के लिए पूछता है और न ही "ऑपरेशन से इंकार" करता है। बेशक YMMV।


0

यहाँ क्या काम किया: ग्राहक पर

1) ssh-add

2) ssh-copy-id यूजर @ सर्वर

चाबियाँ कुछ समय पहले सादे "ssh-keygen -t rsa" के साथ बनाई गई हैं, मैंने त्रुटि संदेश को स्वाइप किया क्योंकि मैंने अपनी ssh सार्वजनिक कुंजी को क्लाइंट से सर्वर पर (ssh-id-copy के साथ) पहले ssh-add को चलाए बिना कॉपी किया था। चूंकि मैंने गलती से मान लिया था कि मैंने उन्हें कुछ समय पहले जोड़ा था।


0

"आधुनिक" ssh संस्करण [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 सितंबर 2019] में अपग्रेड करने वालों के लिए त्वरित नोट - फेडोरा 31 के साथ आपूर्ति की गई, अब पुराने डीएसए SHA256 कुंजी स्वीकार नहीं करना प्रतीत होता है (मेरा दिनांक 2006 है!) - एक नई rsa कुंजी बनाई, जिसे पब्लिक को अधिकृत, क्लाइंट पर निजी, और सब कुछ पूरी तरह से काम करता है।

पिछले सुझावों के लिए धन्यवाद, विशेष रूप से ssh -v बहुत उपयोगी रहा है

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