Ubuntu 16.04 ssh：sign_and_send_pubkey：签名失败：代理拒绝操作

#1 楼

看起来ssh-agent已经在运行，但找不到附加的键。若要解决此问题，请像下面这样将私钥身份添加到身份验证代理：

ssh-add

然后您可以将ssh插入服务器。

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

ssh-add -l

#2 楼

简单的解决方案

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

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

文件权限太开放（0644）。

以下命令解决了该问题：

chmod 600 ~/.ssh/id_rsa

#3 楼

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

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。可以在这里阅读有关该解决方案的文章。

简而言之：


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

如果出现类似问题，该页面将提供其他详细信息。不同的解决方案。

评论

---

您的解决方案对我来说是成功的（具有类似症状的其他问题）。使用步骤1，我收到错误消息“ .ssh / id_rsa”的权限0775太开放。此处的简单解决方案是chmod 600 .ssh / id_rsa。

–马特
18 Mar 26 '18 at 16:25

---

这不仅有助于调试ssh shell连接，还有助于调试git ssh auth。在git pull之前使用此命令SSH_AUTH_SOCK = 0并获得权限警告，如Matt。

– MainActivity
18年11月24日在12:45

---

也为我工作。显然原因是我更改了密钥中的注释，并且很可能是gnome密钥环代理（aka SeaHorse）仍将旧版本保留在内存中

– maoizm
18/12/11在12:09

---

+1，用于检查这是否与GNOME密钥环相关

– Silververdr
19年12月10日14:04

---

我最初的问题是，我首先从模板中获得了一组键，然后在命令行上生成了自己的键。然后例如git pull对我来说失败了。将其与= 0前缀文本一起使用会提示我gnome密钥问题。尝试在其他帖子中给出的解决方案可以解决它。命令是：eval ssh-agent -s ssh-add

–亚历山大·斯托尔
20-2-18在14:38

---

#4 楼

登录多个服务器时，我得到了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-keyring保留在本地计算机上并且出现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是可选的，但像Google Cloud这样的提供程序是必需的。）

评论
是的，但是这删除了所有超级有用的ssh-agent功能



 – Martin Konecny

 17年1月17日在15:42 
密钥环在您自己的本地PC上，因为密钥环是GNOME的一部分，因此通常根本不会将其安装在服务器上。



 –迈克

 17年6月15日在6:20 
@MartinKonecny很好，它只是删除了gnome提供的ssh代理，而没有删除简单的控制台ssh-agent（如果已安装）。问题是，gnome品种妨碍了正常的ssh-agent。您仍然可以启动ssh-agent并在控制台/ shell上输入私钥密码。



 –blubberdiblub

 18-3-18的3:15 
如果您设置为自动登录到DE而不输入密码，则此方法有效，因为实际上您的gnome密钥不会被解锁。



 – xjcl

 19年4月15日在16:46 

#5 楼

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

#6 楼

在我的系统（也是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*（不再需要它们了，它来自早期的测试）一切都恢复了正常。

#7 楼

发生我的原因是我的私钥有密码短语。必须运行ssh-add，然后要求输入密码并正确添加。但是，现在到机器上时，它并不需要我的密码。

#8 楼

我重新安装了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

以后，为了以更永久的方式进行更改，我按照这里的建议

#9 楼

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

解决了

#10 楼

gpg-connect-agent updatestartuptty /bye，然后重试。

#11 楼

添加评论，因为我对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

#12 楼

到了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，组或其他用户为rw），对此有很多答案。所以我在那里什么都不能改变。

在Xubuntu中，有一种禁用启动项的方法。通常也可以在Unity / Gnome / KDE中进行，但是我没有安装这些，因此无法给出具体步骤。不确定其他台式机。我没有禁用SSH代理，GPG代理以及Gnome引起此问题的其他项目以及其他相关错误，而是关闭了所有Gnome启动项目。



在下一次重启时，SSH可以恢复正常工作！

打开Whisker主菜单->设置->会话和启动。
单击“高级”选项卡，在右侧的最后一个选项卡。
取消选中（关闭）启动时启动Gnome服务。
关闭并重新启动。注销也可以这样做，但是应该确保重新启动。

上述GUI的屏幕快照：



因此，自从我在上面给出了修复程序之后，我确实希望有人能够对其进行修复。

事实证明，Ubuntu未能成功压榨它，因为有许多发行版本的票证声称已修复，

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

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

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

#13 楼

ssh-add


对我有用。
但是请确保


ssh-agent


正在运行。

#14 楼

就我而言，问题是由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的干扰。

#15 楼

我的问题是，在从Debian Stretch升级到Debian Buster的过程中，由于无法访问XFCE中的关闭/重新启动按钮，我被迫移至systemd，并且它停止工作并出现相同的错误。

最后发现Debian错误＃851440，解决方案：
apt-get install dbus-user-session。显然，如果要使用gpg-agent（例如，用于OpenPGP智能卡）和pinentry-gnome3下的systemd（在sysvinit下是不需要的，并且系统升级没有安装它），则需要它。

#16 楼

我尝试了几项操作，其中包括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! :)

#17 楼

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

#18 楼

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

#19 楼

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

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

#20 楼

如果您是KeepassXC用户，则可能对该GitHub帖子感兴趣。

Lgmrszd回答：


可以确认此错误。如果启用了“需要用户确认..”复选框，则会发生这种情况，在禁用该复选框并重新启动keepassxc后，它可以正常工作。


我希望可以为您中的某些人解决这种特殊情况。