如何解决“sign_and_send_pubkey:签名失败:代理拒绝操作”?

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

用户/。Ssh /authorized_keys也包含Ssh -rsa密钥条目，但是find name "keynamehere"没有返回任何内容。

当前回答

In my case the problem was that GNOME keyring was holding an invalid passphrase for the ssh key to be used. After spending indecent amount of time troubleshooting this issue I ran seahorse and found the entry to hold empty string. I can only guess that it was caused by mistyping the passphrase at first use some time earlier, and then probably cancelling the requester or so in order to fall back to command line. Updating the entry with correct passphrase immediately solved the problem. Deleting that entry (from "login" keyring) and reentering passphrase at that first prompt (and checking the appropriate checkbox) solves this too. Now agent gets the correct passphrase from the unlocked at login keyring named "login" and neither asks for passphrase nor "refuses operation" anymore. Of course YMMV.

2019-12-10 14:03:28

其他回答

在客户端机器上运行SSH -add，将SSH密钥添加到代理。

使用ssh-add -l(同样在客户端上)确认确实添加了它。

2017-05-29 21:55:01

2019-12-10 14:03:28

导致SSH错误的原因有很多:

Sign_and_send_pubkey:签名失败:代理拒绝操作

其中一些问题可能与其他答案所强调的问题有关(请参阅此线程的答案)，其中一些问题可能被隐藏，因此需要更仔细的调查。

在我的情况下，我得到了以下错误消息:

Sign_and_send_pubkey:签名失败:代理拒绝操作 user@website.domain.com:权限被拒绝(publickey, gsapi -keyex, gsapi -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或directory指的是下一行，而不是上一行。

因此，SSH真正说的是，它无法找到名为id_rsa.website.domain.com-cert的公钥文件，这似乎是我的情况下的问题，因为我的公钥文件不包含-cert后缀。

长话短说:在我的案例中，修复只是确保公钥文件按预期命名。如果不调试连接，我绝不会怀疑这一点。

底线是使用SSH VERBOSE模式(-v选项)来找出哪里出了问题，可能有各种原因，在这个/另一个线程上找不到任何原因。

2018-12-11 10:46:41

只是为了把另一个原因扔进擂台……

我的env被配置为使用金雅拓卡…但是我的~/中有一个名为id_rsa_gemalto_old(.pub)的旧对。Ssh /——名字中有gemalto——足以让git获取导致sign_and_send_pubkey: signing failed: agent refused操作。

(Ubuntu 18.04.6)

2023-01-14 01:43:54

运行以下命令解决此问题。

这对我很管用。