Làm thế nào để giải quyết “sign_and_send_pubkey: ký không thành công: tác nhân từ chối hoạt động”?

Định cấu hình giọt Digital Ocean mới bằng các phím SSH. Khi tôi chạy, ssh-copy-idđây là những gì tôi nhận được:

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.

Tuy nhiên, khi tôi cố gắng truy cập, điều này xảy ra:

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

Sau khi nhập mật khẩu, tôi đã đăng nhập tốt, nhưng điều này tất nhiên đã đánh bại mục đích tạo khóa SSH ngay từ đầu. Tôi đã quyết định xem xét phía máy chủ ssh-agent và đây là những gì tôi nhận được:

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 / allow_keys cũng chứa một mục nhập khóa ssh-rsa, nhưng find -name "keynamehere"không trả về gì.

Chạy ssh-add trên máy khách, điều đó sẽ thêm khóa SSH vào tác nhân.

Xác nhận với ssh-add -l(một lần nữa trên máy khách) rằng nó đã thực sự được thêm vào.

Sau khi nâng cấp Fedora 26 lên 28, tôi gặp phải vấn đề tương tự. Và các nhật ký tiếp theo bị thiếu

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

VẤN ĐỀ:

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

thông báo lỗi không chỉ ra vấn đề thực tế. Sự cố được giải quyết bởi

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

Tôi đã gặp vấn đề tương tự trong Linux Ubuntu 18 . Sau khi cập nhật từ Ubuntu 17.10 , mọi lệnh git sẽ hiển thị thông báo đó.

Cách để giải quyết nó là đảm bảo rằng bạn có quyền chính xác trên id_rsavàid_rsa.pub .

Kiểm tra số chmod hiện tại bằng cách sử dụng stat --format '%a' <file>. Nó phải là 600 cho id_rsa và 644 cho id_rsa.pub.

Để thay đổi quyền đối với tệp, hãy sử dụng

chmod 600 id_rsa
chmod 644 id_rsa.pub

Điều đó đã giải quyết vấn đề của tôi với bản cập nhật.

Chạy lệnh dưới đây để giải quyết vấn đề này.

Nó đã làm việc cho tôi.

chmod 600 ~/.ssh/id_rsa

Tôi đã gặp lỗi khi sử dụng gpg-agent làm ssh-agent và sử dụng khóa con gpg làm khóa ssh https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .

Tôi nghi ngờ rằng sự cố là do có một mục nhập pin không hợp lệ tty cho gpg gây ra bởi lệnh sleep + lock được sử dụng trong cấu hình sway của tôi

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

hoặc chỉ ngủ / tạm ngưng

Đặt lại tty mục nhập pin để khắc phục sự cố

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

và bản sửa lỗi cho lệnh sway sleep + lock của tôi:

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

Đối với lỗi này:

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

Xác minh hoặc thêm lại khóa công khai trong tài khoản Github> hồ sơ> ssh.

Tôi đã giải quyết như thế này:

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

Cảm ơn bạn.

Có thể có nhiều lý do dẫn đến lỗi SSH:

sign_and_send_pubkey: ký không thành công: tác nhân từ chối hoạt động

Một số trong số chúng có thể liên quan đến các vấn đề được đánh dấu bởi các câu trả lời khác (xem câu trả lời của chủ đề này), một số trong số chúng có thể bị ẩn và do đó sẽ yêu cầu điều tra kỹ hơn.

Trong trường hợp của tôi, tôi gặp thông báo lỗi sau:

sign_and_send_pubkey: ký không thành công: tác nhân từ chối hoạt động

user@website.domain.com: Quyền bị từ chối (publickey, gssapi-keyex, gssapi-with-mic)

Cách duy nhất để tìm ra vấn đề thực sự là gọi tùy chọn dài dòng -v dẫn đến việc in ra nhiều thông tin gỡ lỗi:

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

Xin lưu ý rằng dòng nói key_load_public: No such file or directory đang đề cập đến dòng tiếp theo chứ không phải dòng trước đó.

Vì vậy, những gì SSH thực sự nói là nó không thể tìm thấy tệp khóa công khai được đặt tên id_rsa.website.domain.com-certvà đó dường như là vấn đề trong trường hợp của tôi vì tệp khóa công khai của tôi không chứa-cert hậu tố.

Tóm lại: cách khắc phục trong trường hợp của tôi chỉ là đảm bảo rằng tệp khóa công khai được đặt tên như mong đợi. Tôi không bao giờ có thể nghi ngờ điều đó mà không gỡ lỗi kết nối.

Điểm mấu chốt là SỬ DỤNG CHẾ ĐỘ ĐỘNG TỪ SSH (tùy chọn -v) để tìm ra điều gì sai, có thể có nhiều lý do, không có lý do nào có thể được tìm thấy trên chủ đề này / chủ đề khác.

Đây nên là một câu hỏi của SuperUser.

Đúng là tôi gặp phải lỗi tương tự bên trong MacOSX SourceTree, tuy nhiên, bên trong thiết bị đầu cuối iTerm2, mọi thứ hoạt động rất tốt.

Tuy nhiên, vấn đề dường như là tôi có hai lần ssh-agent chạy; (

Bản đầu tiên /usr/bin/ssh-agent(hay còn gọi là MacOSX) và sau đó là HomeBrew được cài đặt /usr/local/bin/ssh-agentđang chạy.

Kích hoạt một thiết bị đầu cuối từ SourceTree, cho phép tôi thấy sự khác biệt trong SSH_AUTH_SOCK, bằng cách sử dụng, lsoftôi tìm thấy hai chữ khác nhau ssh-agentvà sau đó tôi có thể tải các khóa (bằng cách sử dụng ssh-add) vào mặc định của hệ thống ssh-agent(ví dụ /usr/bin/ssh-agent:), SourceTree đã hoạt động trở lại.

Đúng. Chạy ssh-add trên máy khách. Sau đó lặp lại lệnh ssh-copy-id userserver@012.345.67.89

Đối với tôi, vấn đề là sao chép / dán nhầm khóa công khai vào Gitlab. Bản sao tạo ra một lợi nhuận bổ sung. Đảm bảo những gì bạn dán là khóa một dòng.

Tôi cũng có sign_and_send_pubkey: signing failed: agent refused operationlỗi. Nhưng trong trường hợp của tôi, vấn đề là một pinentrycon đường sai lầm .

Trong tôi ${HOME}/.gnupg/gpg-agent.confnhững pinentry-programtài sản đã được trỏ đến một con đường pinentry cũ. Sửa đường dẫn ở đó và khởi động lại đã gpg-agentsửa nó cho tôi.

Tôi đã phát hiện ra nó bằng cách theo dõi các bản ghi với journalctl -f. Ở đó các dòng nhật ký như sau có chứa đường dẫn sai:

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

Tôi cần chia sẻ, vì tôi đã dành quá nhiều thời gian để tìm giải pháp

Đây là giải pháp: https://unix.stackexchange.com/a/351742/215375

Tôi đã sử dụng lệnh này:

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

gnome-keyring không hỗ trợ khóa được tạo.

Loại bỏ -ođối số đã giải quyết được vấn đề.

Trong trường hợp của tôi, vấn đề là GNOME keyring đang giữ một cụm mật khẩu không hợp lệ để sử dụng khóa ssh. Sau khi dành một khoảng thời gian không đứng đắn để khắc phục sự cố này, tôi đã chạy seahorsevà thấy mục nhập chứa chuỗi trống. Tôi chỉ có thể đoán rằng đó là do gõ sai cụm mật khẩu lúc đầu sử dụng một thời gian trước đó và sau đó có thể hủy người yêu cầu hoặc lâu hơn để quay trở lại dòng lệnh. Cập nhật mục nhập với cụm mật khẩu chính xác ngay lập tức giải quyết được vấn đề. Xóa mục nhập đó (khỏi khóa "đăng nhập") và nhập lại cụm mật khẩu ở lời nhắc đầu tiên (và đánh dấu vào hộp kiểm thích hợp) cũng giải quyết được điều này. Bây giờ đại lý nhận được cụm mật khẩu chính xác từ khóa mở khóa khi đăng nhập có tên là "đăng nhập" và không yêu cầu cụm mật khẩu cũng như "từ chối hoạt động" nữa. Tất nhiên là YMMV.

Những gì hoạt động ở đây: trên máy khách

1) ssh-add

2) ssh-copy-id user @ server

Các khóa đã được tạo cách đây một thời gian với "ssh-keygen -t rsa" thuần túy. Tôi chuyển thông báo lỗi vì tôi đã sao chép qua khóa công khai ssh của mình từ máy khách sang máy chủ (với ssh-id-copy) mà không chạy ssh-add trước, vì tôi đã nhầm tưởng rằng tôi đã thêm chúng một thời gian trước đó.

lưu ý nhanh cho những người gần đây đã nâng cấp lên phiên bản ssh "hiện đại" [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 tháng 9 năm 2019] - được cung cấp với fedora 31, dường như không chấp nhận các khóa DSA SHA256 cũ nữa (của tôi là ngày 2006!) - đã tạo một khóa rsa mới, được thêm công khai vào được ủy quyền, riêng tư trên ứng dụng khách và mọi thứ hoạt động hoàn hảo.

cảm ơn vì những đề xuất trước đây, đặc biệt là ssh -v rất hữu ích