如何解决“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"没有返回任何内容。

当前回答

另一个原因是OpenSSH v9.0新默认的NTRU primes + x25519密钥交换，结合gpg-agent(至少在v2.2.32)。

为了解决问题，禁用新的密钥交换算法(因此它的安全效益)，如下:

ssh -o 'KexAlgorithm -sntrup761x25519-sha512@openssh.com' [...]

(SSH配置也一样)

参见https://unix.stackexchange.com/questions/701131/use-ntrux25519-key-exchange-with-gpg-agent

2022-05-02 13:02:21

其他回答

第一个 ssh-add 然后 ssh user@ip

这对我很有效

2020-11-16 19:16:09

在将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/*

2018-06-09 10:22:43

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

我得到了一个sign_and_send_pubkey: signing failed: agent refused操作错误。但在我的案例中，问题是错误的pinentry路径。

在我的${HOME}/.gnupg/gpg-agent.conf中，pinentry-program属性指向一个旧的pinentry路径。修正路径并重新启动gpg-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

2019-07-02 07:51:51

对于这个错误:

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

谢谢你！

2018-06-13 12:55:50

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

推荐文章

最新文章

标签