วิธีแก้ปัญหา“ sign_and_send_pubkey: การลงนามล้มเหลว: ตัวแทนปฏิเสธการดำเนินการ”

การกำหนดค่า Digital Ocean droplet ใหม่ด้วยปุ่ม 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 ตั้งแต่แรก ฉันตัดสินใจดูที่ฝั่งเซิร์ฟเวอร์ ssh-agent และนี่คือสิ่งที่ฉันได้รับ:

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.

user / .ssh / authority_keys มีรายการคีย์ ssh-rsa เช่นกัน แต่find -name "keynamehere"ไม่ส่งคืนอะไรเลย

รันssh-addบนเครื่องไคลเอนต์ซึ่งจะเพิ่มคีย์ SSH ให้กับเอเจนต์

ยืนยันกับssh-add -l(อีกครั้งในไคลเอนต์) ว่ามีการเพิ่มเข้ามาแน่นอน

หลังจากอัปเกรด Fedora 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/*

ผมมีปัญหาเดียวกันในลินุกซ์อูบุนตู 18 หลังจากอัปเดตจากUbuntu 17.10คำสั่ง git ทุกคำสั่งจะแสดงข้อความนั้น

วิธีแก้ปัญหาคือตรวจสอบให้แน่ใจว่าคุณได้รับอนุญาตที่ถูกต้องในid_rsaและid_rsa.pub.

ตรวจสอบหมายเลข chmod ปัจจุบันโดยใช้stat --format '%a' <file>. มันควรจะเป็น600สำหรับid_rsa และ644id_rsa.pubสำหรับ

หากต้องการเปลี่ยนสิทธิ์ในไฟล์ให้ใช้

chmod 600 id_rsa
chmod 644 id_rsa.pub

นั่นช่วยแก้ปัญหาของฉันด้วยการอัปเดต

เรียกใช้คำสั่งด้านล่างเพื่อแก้ไขปัญหานี้

มันได้ผลสำหรับฉัน

chmod 600 ~/.ssh/id_rsa

ผมมีข้อผิดพลาดเมื่อใช้ gpg ตัวแทนเป็นตัวแทน ssh ของฉันและใช้คีย์ย่อย gpg เป็นคีย์ SSH ของฉันhttps://wiki.archlinux.org/index.php/GnuPG#gpg-agent

ฉันสงสัยว่าปัญหาเกิดจากการมีรายการพินไม่ถูกต้อง tty สำหรับ gpg ที่เกิดจากคำสั่ง sleep + lock ที่ใช้ในการกำหนดค่า sway ของฉัน

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

และการแก้ไขคำสั่ง sway sleep + lock ของฉัน:

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

ถึงข้อผิดพลาดนี้:

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

ขอบคุณ.

อาจมีสาเหตุหลายประการในการรับข้อผิดพลาด SSH:

sign_and_send_pubkey: การลงนามล้มเหลว: ตัวแทนปฏิเสธการดำเนินการ

บางส่วนอาจเกี่ยวข้องกับปัญหาที่ไฮไลต์โดยคำตอบอื่น ๆ (ดูคำตอบของเธรดนี้) บางส่วนอาจถูกซ่อนไว้ดังนั้นจึงต้องมีการตรวจสอบอย่างละเอียดยิ่งขึ้น

ในกรณีของฉันฉันได้รับข้อความแสดงข้อผิดพลาดต่อไปนี้:

sign_and_send_pubkey: การลงนามล้มเหลว: ตัวแทนปฏิเสธการดำเนินการ

user@website.domain.com: ปฏิเสธการอนุญาต (คีย์สาธารณะ, gssapi-keyex, gssapi-with-mic)

วิธีเดียวที่จะพบปัญหาที่แท้จริงคือการเรียกใช้ตัวเลือก-v verbose ซึ่งส่งผลให้พิมพ์ข้อมูลการดีบักจำนวนมาก:

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อ้างถึงบรรทัดถัดไปไม่ใช่บรรทัดก่อนหน้า

ดังนั้นสิ่งที่ SSH พูดจริงๆก็คือไม่พบไฟล์คีย์สาธารณะที่ตั้งชื่อid_rsa.website.domain.com-certและดูเหมือนว่าจะเป็นปัญหาในกรณีของฉันเนื่องจากไฟล์คีย์สาธารณะของฉันไม่มี-certคำต่อท้าย

เรื่องสั้นสั้น: การแก้ไขในกรณีของฉันคือเพื่อให้แน่ใจว่าไฟล์คีย์สาธารณะได้รับการตั้งชื่อตามที่คาดไว้ ฉันไม่เคยสงสัยเลยว่าโดยไม่ต้องดีบักการเชื่อมต่อ

บรรทัดล่างสุดคือใช้โหมด SSH VERBOSE (ตัวเลือก -v) เพื่อค้นหาว่ามีอะไรผิดปกติอาจมีสาเหตุหลายประการซึ่งไม่พบในเธรดนี้ / เธรดอื่น

นี่น่าจะเป็นคำถาม SuperUser มากกว่า

ใช่ฉันมีข้อผิดพลาดเดียวกันใน MacOSX SourceTree อย่างไรก็ตามภายในเทอร์มินัล iTerm2 สิ่งต่าง ๆ ทำงานได้ดี

อย่างไรก็ตามปัญหาดูเหมือนว่าฉันกำลังทำงานอยู่สองครั้ง ssh-agent (

สิ่งมีชีวิตแรก/usr/bin/ssh-agent(aka MacOSX) จากนั้นติดตั้ง HomeBrew ที่/usr/local/bin/ssh-agentกำลังทำงานอยู่

การเริ่มต้นเทอร์มินัลจาก SourceTree ทำให้ฉันเห็นความแตกต่างSSH_AUTH_SOCKโดยใช้lsofฉันพบสองssh-agents ที่แตกต่างกันจากนั้นฉันก็สามารถโหลดคีย์ (โดยใช้ssh-add) เป็นค่าเริ่มต้นของระบบssh-agent(เช่น/usr/bin/ssh-agent) SourceTree ก็ทำงานอีกครั้ง

ใช่. เรียกใช้ssh-addบนเครื่องไคลเอนต์ จากนั้นทำซ้ำคำสั่ง ssh-copy-id userserver@012.345.67.89

สำหรับฉันปัญหาคือการคัดลอก / วางคีย์สาธารณะใน Gitlab ไม่ถูกต้อง สำเนาสร้างผลตอบแทนพิเศษ ตรวจสอบว่าสิ่งที่คุณวางเป็นคีย์บรรทัดเดียว

ฉันได้รับ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

ฉันต้องการแบ่งปันเนื่องจากฉันใช้เวลามากเกินไปในการหาวิธีแก้ปัญหา

นี่คือวิธีแก้ปัญหา: https://unix.stackexchange.com/a/351742/215375

ฉันใช้คำสั่งนี้:

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

gnome-keyring ไม่รองรับคีย์ที่สร้างขึ้น

การลบ-oอาร์กิวเมนต์ช่วยแก้ปัญหาได้

ในกรณีของฉันปัญหาคือคีย์ริง GNOME ถือข้อความรหัสผ่านที่ไม่ถูกต้องสำหรับคีย์ ssh ที่จะใช้ หลังจากใช้เวลาที่ไม่เหมาะสมในการแก้ไขปัญหานี้ฉันจึงเรียกใช้seahorseและพบว่ารายการมีสตริงว่าง ฉันเดาได้แค่ว่ามันเกิดจากการพิมพ์ข้อความรหัสผ่านผิดในตอนแรกใช้เวลาก่อนหน้านี้จากนั้นอาจจะยกเลิกผู้ร้องขอหรือมากกว่านั้นเพื่อที่จะกลับไปใช้บรรทัดคำสั่ง การอัปเดตรายการด้วยข้อความรหัสผ่านที่ถูกต้องช่วยแก้ปัญหาได้ทันที การลบรายการนั้น (จากพวงกุญแจ "เข้าสู่ระบบ") และการป้อนข้อความรหัสผ่านอีกครั้งที่ข้อความแจ้งแรกนั้น (และเลือกช่องทำเครื่องหมายที่เหมาะสม) จะช่วยแก้ปัญหานี้ได้เช่นกัน ตอนนี้ตัวแทนได้รับข้อความรหัสผ่านที่ถูกต้องจากการปลดล็อกที่พวงกุญแจล็อกอินชื่อ "เข้าสู่ระบบ" และไม่ขอข้อความรหัสผ่านหรือ "ปฏิเสธการดำเนินการ" อีกต่อไป YMMV แน่นอน

สิ่งที่ทำงานที่นี่: กับลูกค้า

1) ssh เพิ่ม

2) เซิร์ฟเวอร์ ssh-copy-id user @

คีย์ถูกสร้างขึ้นเมื่อไม่นานมานี้ด้วย "ssh-keygen -t rsa" ธรรมดาฉันเปลี่ยนข้อความแสดงข้อผิดพลาดเนื่องจากฉันคัดลอกคีย์สาธารณะ ssh จากไคลเอนต์ไปยังเซิร์ฟเวอร์ (ด้วย ssh-id-copy) โดยไม่เรียกใช้ ssh-add ก่อน เนื่องจากฉันสันนิษฐานผิด ๆ ว่าฉันได้เพิ่มไว้ก่อนหน้านี้

หมายเหตุด่วนสำหรับผู้ที่เพิ่งอัปเกรดเป็นเวอร์ชัน ssh "modern" [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 ก.ย. 2019] - มาพร้อมกับ fedora 31 ดูเหมือนว่าจะไม่ยอมรับคีย์ DSA SHA256 รุ่นเก่าอีกต่อไป (ของฉันลงวันที่ 2006!) - สร้างคีย์ rsa ใหม่เพิ่มสาธารณะในสิทธิ์ส่วนตัวบนไคลเอนต์และทุกอย่างทำงานได้อย่างสมบูรณ์

ขอบคุณสำหรับคำแนะนำก่อนหน้านี้โดยเฉพาะ ssh -v มีประโยชน์มาก