用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"没有返回任何内容。


当前回答

对我来说,问题在于错误地将公钥复制/粘贴到Gitlab中。复制产生了额外的回报。确保你粘贴的是一行键。

其他回答

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.

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

对我来说,问题在于错误地将公钥复制/粘贴到Gitlab中。复制产生了额外的回报。确保你粘贴的是一行键。

正如其他人所提到的,这个错误可能有多种原因。

如果您正在使用SSH with Smart Card (PIV),并将该卡添加到SSH -agent with Ssh-add -s /usr/lib64/pkcs11/opensc-pkcs11.so 你可能会得到错误 Sign_and_send_pubkey:签名失败:代理拒绝操作 如果PIV身份验证已经过期,或者如果您已经移除并重新插入PIV卡,则从ssh登录。

在这种情况下,如果你尝试执行另一个ssh-add -s,你仍然会得到一个错误: 无法添加卡片"/usr/lib64/opensc-pkcs11。所以:代理拒绝操作

根据RedHat Bug 1609055 - pkcs11在代理中的支持是笨拙的,你反而需要做

ssh-add -e /usr/lib64/opensc-pkcs11.so
ssh-add -s /usr/lib64/opensc-pkcs11.so

这应该是一个超级用户的问题。

对的,我在MacOSX SourceTree中有完全相同的错误,然而,在iTerm2终端中,事情工作得很好。

然而,问题似乎是我有两个ssh代理运行;(

第一个是/usr/bin/ssh-agent(也就是MacOSX的),然后是HomeBrew安装的/usr/local/bin/ssh-agent。

从SourceTree启动一个终端,允许我看到SSH_AUTH_SOCK的差异,使用lsof我找到了两个不同的ssh-代理,然后我能够将密钥(使用ssh-add)加载到系统的默认ssh-代理(即。/usr/bin/ssh-agent), SourceTree恢复正常。