Tôi vừa nâng cấp Hệ thống Ubuntu của mình từ 15.10 lên 16.04 bằng cách xóa hoàn toàn phân vùng Ubuntu 15 khỏi hệ thống của tôi.

Sau khi cài đặt Ubuntu 16.04, tôi đã tạo lại các khóa ssh của mình khi tôi quên sao lưu chúng, nhưng bất cứ khi nào tôi cố gắng sử dụng ssh, tôi nhận thấy sign_and_send_pubkey: signing failed: agent refused operationđiều này hơi khó chịu vì nó cho phép tôi truy cập vào máy chủ ssh của mình, nhưng git từ chối đẩy mã bằng ssh.

Tôi đã đẩy các phím đến máy chủ bằng cách sử dụng ssh-copy-id.

Máy chủ tôi đang kết nối là Máy chủ Ubuntu 16.04 được nâng cấp thông qua do-release-upgradelệnh. Chúng tôi rất trân trọng bất kỳ sự giúp đỡ nào.

Có vẻ như một chiếc ssh-agentđã chạy nhưng nó không thể tìm thấy bất kỳ phím nào được đính kèm. Để giải quyết vấn đề này, hãy thêm các danh tính khóa riêng vào tác nhân xác thực như sau:

ssh-add

Sau đó, bạn có thể sshvào máy chủ của bạn.

Ngoài ra, bạn có thể xem danh sách dấu vân tay của tất cả các danh tính hiện được thêm bởi:

ssh-add -l

Giải pháp đơn giản

Tôi gặp vấn đề tương tự ở Ubuntu 18.04. Đó là tất cả về quyền riêng tư phía máy khách .

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

Các quyền của tệp quá mở (0644).

Lệnh sau đã giải quyết nó:

chmod 600 ~/.ssh/id_rsa

Tôi đã có cùng một vấn đề (cùng triệu chứng)

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

... nhưng giải pháp thì khác.

Vấn đề xuất phát từ việc sử dụng Gnome-KEYRING. Bài viết đề cập đến giải pháp có thể được đọc ở đây .

Nói ngắn gọn:

1. Phát hiện sự cố bằng cách thêm SSH_AUTH_SOCK = 0 trước lệnh ssh. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123
2. Trong trường hợp nó thành công để kết nối. Mở ứng dụng StartUp Application (bằng cách sử dụng chức năng tìm kiếm của Desktop chẳng hạn) và vô hiệu hóa việc sử dụng khóa gnome.
3. Khởi động lại

Trang cung cấp các chi tiết khác trong trường hợp có vấn đề tương tự với giải pháp khác nhau.

Tôi đã nhận được sign_and_send_pubkey: signing failed: agent refused operationkhi đăng nhập vào một số máy chủ, đọc câu trả lời của VonC trên Stack Overflow để biết thêm thông tin về các lỗi liên quan, giải pháp cho tôi là xóa khóa gnome, xóa danh tính khỏi ssh-agent và khởi động lại.

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

Sau đó tất cả các phím của tôi bắt đầu hoạt động hoàn hảo.

CẬP NHẬT:

Giải pháp tạm thời mà không cần gỡ cài đặt keyring

Nếu bạn muốn giữ khóa gnome và bạn gặp agent refused operationlỗi, hãy sử dụng:

eval `ssh-agent -s`
ssh-add

hoặc dùng SSH_AUTH_SOCK=0 ssh your-server

Giải pháp vĩnh viễn mà không cần gỡ cài đặt keyring

Nếu bạn có thể, gnome-keyring tương thích với khóa RSA 4096 bit, vì vậy chỉ cần tạo một khóa mới với:

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

Tải khóa công khai lên máy chủ

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

Thêm khóa ssh cho tác nhân

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

Điều này sẽ hoạt động mà không có bất kỳ hack nào và khóa gnome có thể vẫn được cài đặt.

(-C [tên người dùng] là tùy chọn, nhưng được yêu cầu bởi các nhà cung cấp như Google Cloud)

Sau khi nâng cấp lên Ubuntu 18.04, tôi cũng gặp lỗi tương tự sign_and_send_pubkey: signing failed: agent refused operation. Hóa ra là do các quyền của khóa ssh quá mở. Lệnh sau đã khắc phục sự cố cho tôi chmod 600 .ssh/id_rsa

Trên hệ thống của tôi (cũng là Ubuntu 16.04, đang cố gắng kết nối với github), tôi đã có một tệp id_ed25519 trong thư mục .ssh của mình, nó đã ssh-addbị lỗi:

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

Sau khi xóa các tệp ~/.ssh/id_ed25519*(không cần chúng nữa, đó là từ một thử nghiệm trước đó), mọi thứ lại hoạt động tốt trở lại.

Đã xảy ra với tôi vì khóa riêng của tôi có một mật khẩu. Phải chạy ssh-addvà sau đó nó yêu cầu cụm mật khẩu và thêm chính xác. Tuy nhiên, bây giờ nó không yêu cầu cụm mật khẩu của tôi khi ssh'ing vào máy.

Tôi có một bản cài đặt Ubuntu16.04 mới và tôi gặp vấn đề tương tự. Khi tôi cố gắng sao chép kho lưu trữ của mình từ Github sau khi tôi đã sao chép khóa công khai của mình sang github (theo hướng dẫn trên github.com ) và sau khi thực hiện kiểm tra sau (được khuyến nghị trên github.com ):

ssh -T git@github.com

Tôi đã được chào đón bởi những điều sau đây:

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

Để khắc phục nhanh chóng, không xóa bất cứ điều gì hoặc thay đổi cấu hình khởi động của tôi, tôi chỉ cần gõ như sau trong thiết bị đầu cuối:

killall gnome-keyring-daemon

Sau đó, bản sao làm việc. Sau đó tôi bắt đầu lại daemon đã dừng bằng cách gõ:

gnome-keyring-daemon

Sau đó, để thay đổi mọi thứ theo cách lâu dài hơn, tôi đã làm theo lời khuyên ở đây

Sau khi nâng cấp Fedora 26 lên 28, tôi gặp phải vấn đề tương tự. Và không có tệp nhật ký

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:

thông báo lỗi không phải là vấn đề thực tế. Vấn đề được giải quyết bởi

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

Thêm nhận xét khi tôi gặp vấn đề tương tự với các khóa ed25519. Vấn đề thực sự là gnome-keyring. Để khắc phục điều này tôi đã làm như sau:

• Bỏ chọn ssh-key-agent (gnome-keyring) trong "ứng dụng khởi động"
• Giết chết tác nhân ssh và tác nhân gnome: (killall ssh-agent; killall gnome-keyring-daemon)
• Bắt đầu lại daemon: (eval ssh-agent -s)
• Thêm khóa của bạn: $ ssh-add id_ed25519 Nhập cụm mật khẩu cho id_ed25519: Đã thêm danh tính: id_ed25519
• Lợi nhuận!!

Cuối năm 2018, và lỗi này, hoặc các biến thể của nó, vẫn còn gây khó chịu cho Xubfox 16.04 và nhiều khả năng là các hương vị khác của Xenial. Tôi sẽ không ngạc nhiên nếu nó tồn tại vào ngày 18.04! Nó đã xuất hiện ở một số dạng từ năm 2009 và Karmic Koala. Đã ảnh hưởng đến Redhat, Debian và Ubuntu. Đừng hiểu ý tôi, hãy xem các công cụ sửa lỗi công khai:

https://bugs.launchpad.net/ubfox/+source/gnome-keyring/+orms/470456

Và tại lỗi đó, bạn cũng tìm thấy danh sách cho 3 người kia:

Người giới thiệu:

http://bugs.debian.org/cgi-bin/orpreport.cgi?orms=523322

https://ormszilla.redhat.com/show_orms.cgi?id=508286

https://ormszilla.gnome.org/show_orms.cgi?id=576700

Trong trường hợp của tôi, triệu chứng rõ ràng nhất là không thể sử dụng các khóa ssh với cụm mật khẩu. Nó có thể ảnh hưởng đến những cái mà không có, vì trục trặc ngăn chặn các khóa ssh tải! Và tôi không có vấn đề về quyền, tất cả đều là khóa gnome. Các khóa của tôi (vâng, nó đã từ chối một số quyền, đối với các máy chủ SSH khác nhau!) Là tất cả 600 (rw cho chủ sở hữu, không có gì cho nhóm hoặc khác) như đã nêu trong nhiều câu trả lời về điều đó. Vì vậy, không có gì tôi có thể thay đổi ở đó.

Trong Xubfox, có một cách để vô hiệu hóa các mục khởi động. Thông thường cũng có thể có trong Unity / Gnome / KDE, nhưng tôi chưa cài đặt chúng, vì vậy không thể đưa ra các bước cụ thể. Không chắc chắn về máy tính để bàn khác. Thay vì vô hiệu hóa tác nhân SSH, tác nhân GPG và các mục khác từ Gnome gây ra lỗi này và các lỗi liên quan khác, tôi đã tắt tất cả các mục khởi động Gnome. Có thể là quá mức cần thiết hoặc không phải là một tùy chọn cho một số người, nhưng SSH đã trở lại hoạt động hoàn hảo trong lần khởi động lại tiếp theo!

1. Mở Menu chính Whisker -> Cài đặt -> Phiên và Khởi động.
2. Nhấp vào tab Nâng cao, cuối cùng bên phải.
3. Bỏ chọn (tắt) Khởi chạy Dịch vụ Gnome khi khởi động.
4. Đóng và khởi động lại. Đăng xuất cũng có thể làm điều đó, nhưng chắc chắn khởi động lại.

Ảnh chụp màn hình của GUI được mô tả ở trên:

Vì vậy, vì tôi đã đưa ra bản sửa lỗi của mình ở trên, tôi hy vọng ai đó sẽ sửa nó.

Ubuntu đã thất bại trong việc loại bỏ nó mãi mãi, vì có rất nhiều vé cho một số bản phát hành tuyên bố rằng nó đã được sửa, và nhiều hơn nữa nói là "hồi quy", nó đã quay trở lại.

Debian có lẽ muốn chơi khăm (rửa tay) vì đó không phải là họ, ngược dòng là Gnome.

Redhat có lẽ có một sửa chữa chỉ có sẵn cho khách hàng trả tiền. Bởi vì, trong lịch sử, Redhat là nhà tuyển dụng lớn nhất của các nhà phát triển Gnome được trả lương, rất hào phóng ngay từ cái nhìn đầu tiên. Cho đến khi bạn nhận ra điều đó có nghĩa là họ có động cơ tài chính không bao giờ đưa các bản sửa lỗi như thế này vào các phiên bản miễn phí, để tiếp tục bán các đăng ký Redhat.

Gnome có lẽ là người có thể sửa nó dễ dàng nhất, và sau đó những người khác có thể kiểm tra và đóng gói mà không cần tự viết một dòng mã. Nhưng vé tôi đọc nói rằng gói đã mất nhiều năm mà không có người bảo trì chính thức! Và hai người tự nguyện làm như vậy bây giờ (cảm ơn bạn) gần như bận rộn thiết kế một sự thay thế. Tại sao không sửa lốp xe ngay cả khi phải mất một năm (đó là một thập kỷ!) Thay vì phát minh lại bánh xe trước?!

ssh-thêm

làm việc cho tôi Nhưng hãy chắc chắn

đại lý ssh

đang chạy.

Trong trường hợp của tôi, sự cố được gây ra bởi Khóa Gnome. Để vô hiệu hóa các khả năng SSH của gnome-keyring mà không loại bỏ hoàn toàn (làm hỏng rất nhiều thứ), hãy làm theo các hướng dẫn sau:

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

và khởi động lại phiên. Bây giờ bạn có thể chạy ssh-agent mà không cần can thiệp gnome-keyring.

Tôi đã thử một vài thứ, trong số những thứ khác, ssh-add, đặt lại SSH (xóa .ssh / trên máy chủ, và như vậy, nhưng không có may mắn. Vì vậy, hóa ra tôi chỉ phải ngủ qua một đêm. ? Tôi đoán rằng tác nhân ssh đang chạy trên máy chủ có một cái gì đó trong bộ nhớ cache đã được làm mới sau đêm đó với các giá trị phù hợp. Dù sao, bây giờ nó hoạt động như một bùa mê. Để kết thúc, nó đã làm điều này (Ubuntu 16.04 trên localhost, 14.04 trên máy chủ).

# 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! :)

Tôi đã kết thúc việc thả tập tin máy chủ lưu trữ của tôi và nó đã làm việc. Phải đặt lại mật khẩu, nhưng cuối cùng nó cũng chấp nhận đúng mật khẩu. Đó là sau khi cài đặt mới.

Nếu thêm SSH_AUTH_SOCK = 0 trước khi lệnh ssh giúp, thì đó là lỗi khóa gnome. Ngoại trừ các giải pháp và vấn đề được cung cấp, vấn đề có thể liên quan đến cụm mật khẩu. Nếu bạn có cụm mật khẩu cho khóa thì gnome keyring sẽ hỏi nó khi bạn đăng nhập lần đầu và nếu bạn nhập trống do lỗi hoặc đóng cửa sổ bất ngờ, gnome sẽ coi đó là cụm mật khẩu trống và ghi nhớ nó mãi mãi. Không có gì giúp được nhắc lại cho cụm mật khẩu. Để giải quyết ứng dụng khóa ssh mở và đi đến phần Đăng nhập trong danh mục Mật khẩu. Tìm bản ghi tương ứng với khóa có vấn đề và nhập vào Thuộc tính và nhập cụm mật khẩu chính xác.

Có một nguyên nhân khác chưa được giải đáp: định dạng PEM cho tệp khóa đã dừng mặc định ssh-keygentrước khi Ubuntu chuyển sang gnome-keyring-daemonđịnh dạng hỗ trợ định dạng RFC4716 mới.

Nếu bạn tạo khóa mới hoặc thêm / xóa cụm mật khẩu khỏi khóa của mình, khóa đó có thể bị hỏng. Chìa khóa đang sử dụng ssh-keygen -m PEMtrước bất kỳ hoạt động nào khác mà bạn cần chạy. Ví dụ: bạn có thể chuyển đổi trở lại định dạng cũ bằng cách sử dụng ssh-keygen -m PEM -pvà nhập cụm mật khẩu cũ làm cụm mật khẩu mới (sẽ trống không có cụm mật khẩu).