172

मैंने अपने सिस्टम से Ubuntu 15 विभाजन को पूरी तरह से मिटाकर अपने Ubuntu सिस्टम को 15.10 से 16.04 तक अपग्रेड किया।

उबंटू 16.04 को स्थापित करने के बाद मैंने अपनी ssh कुंजियों को फिर से बनाया क्योंकि मैं उन्हें बैकअप देना भूल गया, लेकिन जब भी मैं ssh का उपयोग करने का प्रयास करता हूं तो मुझे sign_and_send_pubkey: signing failed: agent refused operationयह थोड़ा कष्टप्रद होता है क्योंकि यह मुझे मेरे ssh सर्वर के माध्यम से अनुमति देता है, लेकिन gsh ने ssh का उपयोग करके कोड को धक्का देने से इनकार कर दिया है।

मैंने पहले ही सर्वर की कुंजियों का उपयोग करके धक्का दे दिया है ssh-copy-id।

मैं जिस सर्वर से जुड़ रहा हूं वह एक Ubuntu 16.04 सर्वर है जिसे do-release-upgradeकमांड के माध्यम से अपग्रेड किया गया है। किसी भी प्रकार की सहायता सराहनीय होगी।

ssh 16.04

— Gamerb
स्रोत

314

ऐसा लगता है कि कोई ssh-agentपहले से ही चल रहा है, लेकिन इसमें कोई कुंजी नहीं लगी है। इसे हल करने के लिए प्रमाणीकरण एजेंट को निजी प्रमुख पहचानें जोड़ें:

ssh-add

फिर आप sshअपने सर्वर में कर सकते हैं ।

इसके अलावा, आप वर्तमान में जोड़े गए सभी पहचानों के फिंगरप्रिंट की सूची देख सकते हैं:

ssh-add -l

— रॉन
स्रोत

यह नहीं है -1 (संख्या <एक>), यह आपके दूसरे आदेश में -l (लोअरकेस एल) है

— डैनियल एल्डर

3

@ डैनियल एल्डर यह वास्तव में कम मामला है l।

— रॉन

आप सही हैं, क्षमा करें। समस्या Lफॉन्ट "लिबरेशन मोनो" का निचला मामला है :-(

— डैनियल एल्डर

1

मुझे नहीं लगता कि आपको उपयोग करने के ssh-addअलावा अन्य उपयोग करना चाहिए ssh-add -lक्योंकि आप बहुत अधिक प्रविष्टियों के साथ समाप्त कर सकते हैं ssh-agent। मैन्युअल रूप से जोड़ने की कोई आवश्यकता नहीं है। Dash > Startup Applicationsदिखाता है कि ssh-agentयह पहले से ही चल रहा है और यह स्वचालित रूप से फ़ाइलों का पता लगाएगा जैसे कि ~/.ssh/id_rsaऔर ~/.ssh/id_rsa.pub। यह साबित करने के लिए आप उपयोग करने ssh-add -lसे पहले और बाद में उपयोग कर सकते हैं ssh-keygen। आप देखेंगे कि यह फाइलों के लिए मॉनिटर करता है इसलिए आपको उन्हें मैन्युअल रूप से जोड़ना नहीं पड़ता है।

— H2ONaCl

1

इसी तरह उपयोग नहीं करते हैं ssh-add -dऔर ssh-add -Dमैनुअल हटाने के लिए प्रदर्शन करते हैं। बस कुंजी फ़ाइलों को हटाने ~/.ssh/id_rsaऔर ~/.ssh/id_rsa.pubऔर ssh-agentइच्छा नोटिस। यह साबित करने के लिए कि आप ssh-add -lकुंजी फ़ाइलों को हटाने से पहले और बाद में कर सकते हैं ।

— H2ONaCl

56

सरल उपाय

मुझे उबंटू 18.04 पर यही समस्या थी। यह सब क्लाइंट-साइड निजी कुंजी अनुमतियों के बारे में है ।

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

फ़ाइल अनुमतियां बहुत खुली थीं (0644)।

निम्नलिखित कमांड ने इसे हल किया:

chmod 600 ~/.ssh/id_rsa

— एंटोनियो फीटोसा
स्रोत

2

पथ इस तरह पूर्ण होना चाहिए: सभी मामलों पर काम करने के लिए chmod 600 ~ / .sh / id_rsa।

— उमर अल्हम्मद

54

मुझे एक ही समस्या थी (एक ही लक्षण)

sam@xxxxx:~/.ssh$ ssh centos@123.123.123.123
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

... लेकिन समाधान अलग था।

समस्या GNOME-KEYRING के उपयोग से आ रही थी। समाधान का जिक्र करने वाला पद यहां पढ़ा जा सकता है ।

संक्षेप में:

SSH_AUTH_SOCK = 0 को ssh कमांड के सामने जोड़कर समस्या का पता लगाएं। sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123
मामले में यह कनेक्ट करने में सफल होता है। एप्लिकेशन स्टार्टअप एप्लिकेशन खोलें (उदाहरण के लिए डेस्कटॉप के खोज फ़ंक्शन का उपयोग करके) और सूक्ति-कीरिंग के उपयोग को अक्षम करें।
रीबूट

पृष्ठ अलग-अलग समाधान के साथ समान समस्या के मामले में अन्य विवरण प्रदान करता है।

— सैम
स्रोत

24

आपके समाधान ने मेरे लिए आधा काम किया (समान लक्षणों के साथ अलग समस्या)। चरण 1 का उपयोग करके मुझे त्रुटि संदेश मिला Permissions 0775 for '.ssh/id_rsa' are too open। यहाँ सरल समाधान था chmod 600 .ssh/id_rsa।

— मैट

1

यह न केवल ssh शेल कनेक्शन को डिबग करने में मदद करता है, बल्कि sit ऑर्ट को भी हटाता है। SSH_AUTH_SOCK=0पहले इस कमांड का इस्तेमाल किया git pullऔर मैट की तरह परमिशन की चेतावनी दी।

— सर्ज

मेरे लिए भी काम किया। जाहिरा तौर पर कारण यह था कि मैंने अपनी कुंजी में टिप्पणी बदल दी है और संभवत: गनोम कीरिंग एजेंट (उर्फ सीहोरसे) अभी भी पुराने संस्करण को स्मृति में रख रहा था

— maoizm

18

sign_and_send_pubkey: signing failed: agent refused operationजब मैं कई सर्वरों में लॉग इन कर रहा था , संबंधित बग्स के बारे में अधिक जानकारी के लिए स्टैक ओवरफ्लो पर VonC का उत्तर पढ़ें , मेरे लिए समाधान सूक्ति-एजेंट को हटाने, ssh- एजेंट से पहचान हटाने और रिबूट करना था।

sudo apt-get autoremove gnome-keyring
ssh-add -D

फिर मेरी सारी चाबियां पूरी तरह से काम करने लगीं।

अपडेट करें:

कीरिंग को अनइंस्टॉल किए बिना अस्थायी समाधान

यदि आप सूक्ति-कुंजी रखना चाहते हैं और आपके पास agent refused operationत्रुटि है, तो उपयोग करें:

eval `ssh-agent -s`
ssh-add

या उपयोग करें SSH_AUTH_SOCK=0 ssh your-server

कीरिंग की स्थापना के बिना स्थायी समाधान

यदि आप कर सकते हैं, सूक्ति-कीरिंग 4096 बिट आरएसए कुंजी के साथ संगत है, तो बस इसके साथ एक नई कुंजी उत्पन्न करें:

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

सर्वर पर सार्वजनिक कुंजी अपलोड करें

$ ssh-copy-id -i ~/.ssh/your-key-name.pub root@12.34.56.78

एजेंट के लिए ssh कुंजी जोड़ें

ssh-add ~/.ssh/your-key-name

यह बिना किसी अतिरिक्त हैक के काम करना चाहिए और सूक्ति-कीरिंग स्थापित रह सकता है।

(-C [उपयोगकर्ता नाम] वैकल्पिक है, लेकिन Google क्लाउड जैसे प्रदाताओं द्वारा आवश्यक है)

— माइक
स्रोत

2

हां, लेकिन यह सभी ssh- एजेंट कार्यक्षमता को हटा देता है जो सुपर उपयोगी है

— मार्टिन कोंकनी

कृपया ध्यान दें कि किस पीसी में sudo apt-get, हमारे अपने कंप्यूटर या रिमोट सर्वर का उपयोग करना है। धन्यवाद।

— शिचेंग गुओ

अपने स्वयं के स्थानीय पीसी पर कीरिंग करना, क्योंकि कीरिंग गनोम का हिस्सा है, यह आमतौर पर सर्वर पर स्थापित नहीं होता है।

— माइक

1

@MartinKonecny अच्छी तरह से, यह सिर्फ ssh एजेंट को हटाता है जो कि सूक्ति द्वारा प्रदान किया गया है, यह सादे और सरल कंसोल ssh- एजेंट को नहीं हटाता है (यदि आपने वह इंस्टॉल किया है)। समस्या यह है कि सामान्य के रास्ते में सूक्ति किस्म मिलती है ssh-agent। आप अभी भी ssh- एजेंट शुरू कर सकते हैं और कंसोल / शेल पर निजी कुंजी पासवर्ड दर्ज कर सकते हैं।

— ब्लबरडाइब्लूब

यह तब काम करता है जब आपने अपना पासवर्ड दर्ज किए बिना अपने DE में अपने आप लॉगिन करने की तैयारी कर ली है, क्योंकि तब वास्तव में आपके सूक्ति-कीरिंग को अनलॉक नहीं किया जाएगा।

— xjcl

14

उबंटू 18.04 में अपग्रेड करने के बाद मुझे वही त्रुटि मिली sign_and_send_pubkey: signing failed: agent refused operation। पता चलता है कि यह ssh कुंजी की अनुमति के कारण खुला था। निम्नलिखित कमांड ने मेरे लिए समस्या तय की chmod 600 .ssh/id_rsa

— मथायस
स्रोत

8

मेरे सिस्टम पर (Ubuntu 16.04 भी, github से कनेक्ट करने की कोशिश कर रहा है), मेरे पास मेरे .shsh फ़ोल्डर में एक फ़ाइल id_ed25519 था जो ssh-addविफल हो गया था:

$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed

फ़ाइलों को हटाने के बाद ~/.ssh/id_ed25519*(अब उनकी आवश्यकता नहीं थी, यह पहले के परीक्षण से था) सब कुछ फिर से ठीक हो गया।

— डैनियल एल्डर
स्रोत

2

और अगर आपको उनकी ज़रूरत है तो क्या होगा?

— ग्रिंगो सुवे

@GringoSuave अच्छा सवाल। क्या आप ने कोशिश की? शायद प्रारूप बदल गया है या ssh द्वारा अब समर्थित नहीं है - या यह एक बग है। व्यक्तिगत रूप से, मैं खुश था कि मुझे इसका परीक्षण नहीं करना पड़ा ...

— डैनियल एल्डर

अभी भी मेरे लिए काम नहीं कर रहा है, मेरे पास कोई समाधान नहीं है: Could not add identity "~/.ssh/id_ed25519": communication with agent failedएजेंट चल रहा है और कॉन्फ़िगर किया गया है जहाँ तक मैं बता सकता हूं।

— ग्रिंगो सुवे

2

@GringoSuave यहाँ समाधान भी है जो गनोम प्रमाणीकरण एजेंट से छुटकारा पाने के लिए है जो सादे ssh-agentसॉकेट के स्थान पर आपके शेल पर एक एजेंट सॉकेट को रोकता है । सादे ssh- एजेंट ED25519 कुंजी को संभालने में सक्षम है, जबकि सूक्ति प्रमाणीकरण एजेंट नहीं है (इसके अलावा अन्य समस्याओं के कारण)।

— Sam

7

मेरे पास आया क्योंकि मेरी निजी कुंजी में पासफ़्रेज़ था। दौड़ना पड़ा ssh-addऔर फिर उसने पासफ़्रेज़ के लिए कहा और सही तरीके से जोड़ा। हालाँकि, यह अब मेरे पासफ़्रेज़ के लिए नहीं पूछता है जब एक मशीन के लिए ssh'ing।

— qwertzguy
स्रोत

6

मेरे पास Ubuntu16.04 की एक नई स्थापना है और मैंने इसी तरह की समस्याओं का अनुभव किया है। जब मैंने अपनी सार्वजनिक कुंजी को github ( github.com के निर्देशों के अनुसार ) में कॉपी किया था और उसके बाद निम्नलिखित चेक ( github.com पर अनुशंसित ) को ले जाने के बाद मैंने अपनी रिपॉजिटरी को क्लोन करने की कोशिश की :

ssh -T git@github.com

मैं निम्नलिखित द्वारा अभिवादन किया गया था:

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

बिना किसी चीज को हटाए या अपना स्टार्टअप कॉन्फ़िगरेशन बदले, इसे जल्दी से ठीक करने के लिए, मैंने टर्मिनल में निम्नलिखित टाइप किया:

killall gnome-keyring-daemon

फिर क्लोन ने काम किया। मैंने तब बंद डेमॉन को फिर से टाइप करके शुरू किया:

gnome-keyring-daemon

बाद में, चीजों को और अधिक स्थायी तरीके से बदलने के लिए, मैंने यहां सलाह का पालन किया

— neiltheory
स्रोत

यह मेरे लिए काम करता है, इसे उच्चतर होना चाहिए

— शेषांक एस।

4

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

no /var/log/secure
no /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/*

— Anto
स्रोत

2

टिप्पणी जोड़ने के रूप में मैं ed25519 कुंजी के साथ एक ही मुद्दा था। मुद्दा वास्तव में सूक्ति-कीरिंग है। इसे ठीक करने के लिए मैंने निम्नलिखित कार्य किया:

"स्टार्टअप अनुप्रयोगों" में अनियंत्रित ssh-key-agent (सूक्ति-कीरिंग)
Ssh-agent और gnome Agent को मार दिया गया: (हत्यारे ssh-agent; किलॉल gnome-keyring-daemon)
डेमॉन को फिर से शुरू किया: (eval ssh-agent -s)
अपनी कुंजी जोड़ें: $ ssh-add id_ed25519 id_ed25519 के लिए पासफ़्रेज़ दर्ज करें: पहचान जोड़ी गई: id_ed25519
फायदा!!

— मैट
स्रोत

2

यह 2018 के अंत में है, और यह बग, या इसके रूपांतर, अभी भी Xubuntu 16.04 को प्लेग करते हैं, और Xenial के अन्य स्वादों की तुलना में अधिक है। मुझे आश्चर्य नहीं होगा अगर यह 18.04 में भी मौजूद है! यह 2009 और कर्मिक कोअला के बाद से किसी न किसी रूप में है। रेडहैट, डेबियन और उबंटू को प्रभावित किया है। इसके लिए मेरा शब्द न लें, सार्वजनिक बगट्रैक देखें:

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

और उस बग पर, आप अन्य 3 के लिए भी लिस्टिंग पाते हैं:

संदर्भ:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=576700

मेरे मामले में, सबसे स्पष्ट लक्षण पासफ़्रेज़ के साथ ssh कुंजियों का उपयोग करने में असमर्थता थी। यह बिना प्रभावित लोगों को भी प्रभावित कर सकता है, क्योंकि खराबी ssh कुंजी को लोड करने से रोकती है! और मुझे कोई अनुमति समस्या नहीं थी, यह सभी सूक्ति-कीरिंग था। मेरी कुंजियाँ (हाँ यह कई लोगों के लिए इनकार कर दिया, विभिन्न SSH सर्वरों के लिए!) अनुमतियाँ सभी 600 थीं (स्वामी के लिए rw, समूह या अन्य के लिए कुछ भी नहीं) जैसा कि उस बारे में कई उत्तरों में कहा गया है। इसलिए कुछ भी मैं वहां नहीं बदल सकता था।

Xubuntu में, स्टार्टअप आइटम को अक्षम करने का एक तरीका है। आमतौर पर एकता / सूक्ति / केडीई में भी संभव है, लेकिन मेरे पास वे स्थापित नहीं हैं, इसलिए विशिष्ट कदम नहीं दे सकते हैं। अन्य डेस्कटॉप के बारे में निश्चित नहीं है। SSH एजेंट, GPG एजेंट और Gnome के अन्य आइटमों को अक्षम करने के बजाय जो इसका कारण बनते हैं, और अन्य संबंधित बग, मैंने सभी Gnome स्टार्टअप आइटम बंद कर दिए। ओवरकिल हो सकता है या कुछ के लिए एक विकल्प नहीं हो सकता है, लेकिन एसएसएच अगले रिबूट पर निर्दोष रूप से काम कर रहा है!

व्हिस्कर मुख्य मेनू खोलें -> सेटिंग्स -> सत्र और स्टार्टअप।
उन्नत टैब पर क्लिक करें, दाईं ओर अंतिम।
अनचेक करें (बंद करें) स्टार्टअप पर Gnome सेवाएँ लॉन्च करें।
बंद करें और रिबूट करें। लॉग आउट करना भी हो सकता है, लेकिन रिबूट सुनिश्चित करना चाहिए।

ऊपर वर्णित GUI का स्क्रीनशॉट:

इसलिए, जब से मैंने अपना फिक्स ऊपर दिया, मुझे उम्मीद है कि कोई इसे ठीक कर देगा।

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

डेबियन संभवत: पंट (इसके हाथों को धोना) चाहती है क्योंकि यह उन्हें नहीं है, अपस्ट्रीम ग्नोम है।

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

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

— लुबो डियाकोव
स्रोत

1

ssh-ऐड

मेरे लिये कार्य करता है। लेकिन यकीन रखिए

ssh-एजेंट

दौड रहा है।

— KST
स्रोत

1

मेरे मामले में समस्या गनोम कीरिंग के कारण हुई। इसे हटाने के बिना सूक्ति-कीरिंग की SSH क्षमताओं को निष्क्रिय करने के लिए (जो बहुत सी चीजों को तोड़ता है), इन निर्देशों का पालन करें :

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

और सत्र को पुनः आरंभ करें। अब आप gnome-keyring हस्तक्षेप के बिना ssh-Agent चला सकते हैं।

— Norrius
स्रोत

0

मैंने कुछ चीजों की कोशिश की, दूसरों के बीच ssh-add, SSH को रीसेट करना (सर्वर पर डिलीट करना। ssh / और इस तरह का, लेकिन कोई किस्मत नहीं। तो यह निकला कि मुझे बस एक रात के लिए सोना पड़ा। इससे मदद मिली! क्यों!) ? मुझे लगता है कि सर्वर पर चल रहे ssh- एजेंट के कैश में कुछ था जो बाद में उस रात को उचित मूल्यों के साथ ताज़ा किया गया था। किसी भी तरह, यह अब एक आकर्षण की तरह काम करता है। रैप करने के लिए, इसने (Ubuntu 16.04 लोकलहोस्ट पर 16.04)। 14.04 सर्वर पर)।

# on local host:
$ ssh-keygen
# (yes, overwrite the default file, and let the passphrase be empty)
$ ssh-copy-id ***.***.*.**
# (insert proper server IP address)
# now test
$ ssh ***.***.*.**
# this should have erected in .ssh/ on the server:
# -rw------- 1 *** *** 2000 aug.  11 09:55 authorized_keys
# no other magic going on! :)

— तक
स्रोत

0

मैंने अपनी ज्ञात होस्ट फ़ाइल को छोड़ दिया और यह काम कर गई। फिर से पासवर्ड लगाना पड़ता था, लेकिन अंत में उसने सही पासवर्ड स्वीकार कर लिया। यह एक नई स्थापना के बाद था।

— possumkeys
स्रोत

0

यदि ssh कमांड मदद करने से पहले SSH_AUTH_SOCK = 0 जोड़ रहा है, तो यह सूक्ति कीरिंग गलती है। प्रदान किए गए समाधानों और समस्याओं को छोड़कर, समस्या पासफ़्रेज़ से संबंधित हो सकती है। यदि आपके पास कुंजी के लिए पासफ़्रेज़ है, तो सूक्ति कीरिंग आपसे यह पूछती है कि आप पहली बार कब लॉगिन करते हैं और यदि आप गलती से या अनपेक्षित रूप से बंद खिड़की से खाली प्रवेश करते हैं, तो सूक्ति इसे खाली पासफ़्रेज़ के रूप में मानता है और इसे हमेशा याद रखता है। पासफ़्रेज़ के लिए फिर से संकेत दिए जाने में कुछ भी मदद नहीं करता है। ओपन ssh कीरिंग ऐप को हल करने के लिए और पासवर्ड श्रेणी के तहत लॉगिन सेक्शन में जाएं। समस्याग्रस्त कुंजी के लिए इसी रिकॉर्ड का पता लगाएं और गुण दर्ज करें और सही पासफ़्रेज़ दर्ज करें।

— Fazliddin
स्रोत

0

इसका एक और कारण है जो अभी तक किसी भी जवाब में नहीं है: कुंजी फ़ाइल के लिए पीईएम प्रारूप ssh-keygenउबंटू में स्थानांतरित होने से पहले डिफ़ॉल्ट होना बंद हो जाता gnome-keyring-daemonहै जो नए RFC4716 प्रारूप का समर्थन करता है।

यदि आप एक नई कुंजी उत्पन्न करते हैं, या अपनी कुंजी से पासफ़्रेज़ जोड़ते / हटाते हैं, तो यह टूट सकता है। कुंजी का उपयोग करने ssh-keygen -m PEMसे पहले आपको जो भी अन्य ऑपरेशन चलाने की आवश्यकता है। उदाहरण के लिए, आप ssh-keygen -m PEM -pपुराने पासफ़्रेज़ को नए पासफ़्रेज़ (जो बिना पासफ़्रेज़ के खाली होगा) के रूप में उपयोग करके और पुराने पासफ़्रेज़ में दर्ज करके पुराने प्रारूप में वापस परिवर्तित कर सकते हैं।

— सैम ब्राइटमैन
स्रोत

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

सरल उपाय