我刚刚通过从系统中完全擦除Ubuntu 15分区，将Ubuntu System从15.10升级到16.04。

安装Ubuntu 16.04之后，我忘记了备份它们而重新创建了ssh密钥，但是每当我尝试使用ssh时，都会sign_and_send_pubkey: signing failed: agent refused operation有点烦人，因为它使我可以进入ssh服务器，但是git拒绝使用ssh推送代码。

我已经通过使用键将密钥推到了服务器ssh-copy-id。

我要连接的服务器是通过do-release-upgrade命令升级的Ubuntu 16.04服务器。任何帮助将不胜感激。

似乎ssh-agent已经在运行，但找不到任何附加的键。为了解决这个问题，将私钥身份添加到身份验证代理，如下所示：

ssh-add

然后，您可以ssh进入服务器。

此外，您还可以查看当前由以下人员添加的所有身份的指纹列表：

ssh-add -l

简单的解决方案

我在Ubuntu 18.04上遇到了同样的问题。这就是关于客户端私钥权限的全部内容。

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

文件权限太开放（0644）。

以下命令解决了该问题：

chmod 600 ~/.ssh/id_rsa

我有同样的问题（症状相同）

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

...但是解决方案有所不同。

问题来自使用GNOME-KEYRING。有关解决方案的帖子可以在这里阅读。

简而言之：

1. 通过在ssh命令之前添加SSH_AUTH_SOCK = 0来检测问题。sam @ xxxxx：〜/ .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123
2. 万一成功连接。打开应用程序启动应用程序（例如，使用桌面的搜索功能），然后禁用gnome-keyring。
3. 重启

该页面提供了其他详细信息，以防类似问题的解决方案不同。

sign_and_send_pubkey: signing failed: agent refused operation登录到多台服务器时，我遇到了问题，请阅读VonC在Stack Overflow上的答案以获取有关相关错误的更多信息，对我来说，解决方案是删除gnome-keyring，从ssh-agent中删除身份并重新启动。

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

然后，我所有的按键开始完美工作。

更新：

无需卸载密钥环的临时解决方案

如果您想保留gnome密钥，并出现agent refused operation错误，请使用：

eval `ssh-agent -s`
ssh-add

或使用 SSH_AUTH_SOCK=0 ssh your-server

无需卸载密钥环的永久解决方案

如果可以，gnome-keyring与4096位RSA密钥兼容，因此只需使用以下命令生成一个新密钥：

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

将公钥上传到服务器

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

将ssh密钥添加到代理

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

这应该可以正常工作，而无需任何其他黑客，并且可以保持gnome-keyring的安装状态。

（-C [用户名]是可选的，但像Google Cloud这样的提供程序是必需的）

升级到Ubuntu 18.04之后，出现了同样的错误sign_and_send_pubkey: signing failed: agent refused operation。原来，这是由于ssh密钥的权限过于开放引起的。以下命令为我解决了问题 chmod 600 .ssh/id_rsa

在我的系统（也是Ubuntu 16.04，尝试连接到github）上，我的.ssh文件夹中有一个文件id_ed25519，导致ssh-add失败：

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

删除文件后~/.ssh/id_ed25519*（不再需要它们了，这是来自较早的测试），一切都恢复了正常。

发生我的原因是我的私钥有密码短语。必须运行ssh-add，然后要求输入密码并正确添加。但是，现在在向计算机发送命令时，它不会要求我输入密码。

我重新安装了Ubuntu16.04，遇到了类似的问题。当我尝试将我的公钥复制到github（按照github.com上的说明）并执行以下检查（推荐在github.com上）之后从Github克隆存储库时：

ssh -T git@github.com

我受到以下欢迎：

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

为了快速修复它，而不删除任何内容或更改我的启动配置，我只在终端中输入了以下内容：

killall gnome-keyring-daemon

然后克隆成功了。然后，我通过键入以下内容再次启动已停止的守护程序：

gnome-keyring-daemon

后来，为了以更永久的方式进行更改，我遵循了这里的建议

将Fedora 26升级到28后，我遇到了同样的问题。而且没有日志文件

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:

错误消息未指出实际问题。问题由解决

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

添加评论，因为我对ed25519键有同样的问题。这个问题确实是gnome-keyring。为了解决这个问题，我做了以下工作：

• 在“启动应用程序”中未选中的ssh-key-agent（gnome-keyring）
• 杀死了ssh-agent和gnome代理：（killall ssh-agent； killall gnome-keyring-daemon）
• 重新启动守护程序：（eval ssh-agent -s）
• 添加密钥：$ ssh-add id_ed25519输入id_ed25519的密码：已添加身份：id_ed25519
• 利润！！

到了2018年末，这个bug或它的变种仍然困扰着Xubuntu 16.04，而且可能还超过了Xenial的其他口味。如果它也存在于18.04中，我不会感到惊讶！自2009年以来，它和Karmic Koala就以某种形式出现了。影响了Redhat，Debian和Ubuntu。不要相信我，请查看公共的bugtrackers：

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

在该错误处，您还会找到其他3的清单：

参考文献：

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=576700

就我而言，最明显的症状是无法将ssh密钥与密码短语一起使用。由于故障会根本无法加载ssh密钥，因此也可能会影响到ssh密钥！而且我没有权限问题，全都是gnome密钥管理。我的密钥（是的，对于不同的SSH服务器，它拒绝了几个密钥！）权限全部为600（所有者为rw，对于组或其他都不为），对此有很多答案。所以我在那里什么都不能改变。

在Xubuntu中，有一种方法可以禁用启动项。通常也可以在Unity / Gnome / KDE中进行，但是我没有安装，因此无法给出具体步骤。不确定其他台式机。我没有禁用SSH代理，GPG代理以及Gnome引起此问题的其他项目以及其他相关错误，而是关闭了所有Gnome启动项目。可能有些大材小用或不是一种选择，但是SSH在下次重新启动时又恢复了正常工作！

1. 打开“晶须主菜单”->“设置”->“会话和启动”。
2. 单击高级选项卡，然后单击右侧的最后一个。
3. 取消选中（关闭）启动时启动Gnome服务。
4. 关闭并重新启动。注销也可以，但是一定要重新启动。

上述GUI的屏幕截图：

因此，由于我在上面给出了修复程序，所以我希望有人能够对其进行修复。

事实证明，Ubuntu未能成功压榨它，因为有许多发行版本的票证声称它已修复，而更多的说法是“回归”，它又回来了。

Debian可能想要戳（洗手），因为不是他们，上游是Gnome。

Redhat可能仅提供给付费客户的修复程序。因为从历史上看，Redhat是付费Gnome开发人员的最大雇主，乍一看是慷慨的。除非您意识到这意味着他们有经济上的动力，否则决不要将这样的修补程序放入免费版本中，以继续销售Redhat订阅。

Gnome可能是最容易在上游修复它的人，然后其他人可以测试和打包，而无需自己编写代码。但是我读到的票说，这个套餐在没有官方维护者的情况下已经停滞了多年！现在，两个自愿这样做的人（谢谢您）几乎都在忙于设计替代产品。为什么要花上一年（十年！）而不是修理轮胎，而不是先修理车轮呢？

SSH添加

为我工作。但是请确保

SSH代理

在跑。

就我而言，问题是由GNOME密钥环引起的。要禁用 gnome-keyring的SSH功能而不直接删除它（这会破坏很多事情），请遵循以下说明：

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

并重新启动会话。现在，您可以运行ssh-agent而不会受到gnome-keyring的干扰。

我尝试了几项操作，其中包括ssh-add，重置SSH（在服务器上删除.ssh /等），但是没有运气。因此，事实证明我只需要睡了一晚。这很有帮助！为什么！ ？我猜服务器上运行的ssh-agent缓存中有一些东西，当晚晚些时候用现在正确的值刷新了。无论如何，它现在就像一个符咒。总而言之，它做到了这一点（在localhost上的Ubuntu 16.04，服务器上的14.04）。

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

我最终删除了我的已知主机文件，它正常工作。不得不再次输入密码，但是它最终接受了正确的密码。这是在新安装之后。

如果在ssh命令帮助之前添加SSH_AUTH_SOCK = 0，则是gnome密钥环错误。除提供的解决方案和问题外，问题可能与密码短语有关。如果您有用于密钥的密码短语，则gnome密钥环在您首次登录时会询问它，并且如果您因错误而输入为空或意外关闭窗口，则gnome会将其假定为空密码短语并永远记住它。密码提示无济于事。要解决打开ssh keyring应用程序的问题，请转到“密码”类别下的“登录”部分。查找与有问题的密钥相对应的记录，然后输入“属性”并输入正确的密码。

造成此问题的另一个原因尚未解决：ssh-keygen在Ubuntu迁移到gnome-keyring-daemon支持新RFC4716格式的之前，密钥文件的PEM格式已不再是默认格式。

如果您生成新密钥，或从密钥中添加/删除密码，则密码可能会损坏。关键是ssh-keygen -m PEM在需要执行任何其他操作之前先使用。例如，您可以通过使用ssh-keygen -m PEM -p旧的密码短语并将其输入为新的密码短语来转换回旧的格式（如果没有密码短语则为空）。