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


当前回答

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

这对我很有效

其他回答

我在Linux Ubuntu 18中遇到了同样的问题。从Ubuntu 17.10更新之后,每个git命令都会显示这条消息。

解决方法是确保您对id_rsa和id_rsa.pub拥有正确的权限。

使用stat——format '%a' <file>检查当前的chmod编号。 id_rsa应该是600,id_rsa.pub应该是644。

更改文件使用的权限

chmod 600 id_rsa
chmod 644 id_rsa.pub

这解决了我更新的问题。

这可能导致1password不支持ssh-rsa密钥交换。出于安全考虑,它们支持更新的rsa-sha-512和rsa-sha-256。

https://1password.community/discussion/comment/632712/#Comment_632712

注意如何命名ssh密钥文件

如果您有多个密钥对,您可以使用ssh-keygen和-f <密钥名称>来命名输出文件。在我的例子中,我将密钥命名为username@organization和username@organization.pub,这有助于保持多个密钥对的组织。

问题是ssh代理不喜欢@字符。

在我的例子中,这导致了sign_and_send_pubkey: signing failed: agent refused操作错误,并阻止会话密匙环与ssh代理交互。

将密钥文件重命名为username_at_organization解决了这个问题。

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

这对我很有效

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.