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


110

使用SSH密钥配置新的Digital Ocean Droplet。当我运行时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.

user / .ssh / authorized_keys确实也包含ssh-rsa密钥条目,但不find -name "keynamehere"返回任何内容。

Answers:


195

ssh-add在客户端计算机上运行,这会将SSH密钥添加到代理。

确认ssh-add -l它的确是添加(客户端再次上)。


7
哎呀,花了两个小时试图解决这个问题,仅此而已!固定的bitbucket和acquia ssh连接
Ronnie

18
当我使用gpg-agentSSH功能时,它并没有完全解决此问题。我已经有一个enable-ssh-supportgpg-agent.conf,但还是同样的错误消息。我在邮件列表中发现可以运行以下命令gpg-connect-agent updatestartuptty /bye::bugs.debian.org/cgi-bin/bugreport.cgi?bug=835394
Roland

1
我只需要杀死gpg-agent,然后再次运行即可。
Subin

3
生成新的SSH密钥时,ssh-add必须调用,以ssh-agent使SSH 知道新的私有密钥(每个linux.die.net/man/1/ssh-agent)。
亚历克斯

太好了!我重新创建了SSH密钥,这开始发生。之后ssh-add它的工作!谢谢。
hbobenicio

65

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

.ssh/没有所需的权限,因为我是自己手动创建的。
布伦特·布拉德本

1
似乎某些版本不允许您的密钥对其他用户可见。谢谢!
阿兰·ocallaghan

如果.ssh / *文件是由同一用户(不是root用户)创建的,则不必担心,因为它具有必需的权限。
安托

1
我必须感谢你。我刚才遇到了这个问题。用你的方法解决了。
土地

55

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

解决此问题的方法是确保您对id_rsa和具有正确的权限id_rsa.pub

使用检查当前的chmod编号stat --format '%a' <file>。它应该是600id_rsa644id_rsa.pub

要更改文件的权限,请使用

chmod 600 id_rsa
chmod 644 id_rsa.pub

这就解决了我的更新问题。


3
在将Ubuntu从16.04 LTS迁移到18.04 LTS后,我遇到了这个问题,该解决方案对我有用。
Munish Chandel

同样,在将Ubuntu更新到18.04之后,我遇到了这个问题。此解决方案将其修复。
Cartucho

id_rsa.pub客户端身份验证过程中何时使用?
Dimitri Kopriwa

如果您有很多键,则应在内部使用以下内容~/.sshchmod 600 id_*
lifeisfoo

10

运行以下命令来解决此问题。

它为我工作。

chmod 600 ~/.ssh/id_rsa

5

使用gpg-agent作为ssh-agent和使用gpg子项作为我的ssh密钥时出现错误https://wiki.archlinux.org/index.php/GnuPG#gpg-agent

我怀疑问题是由在sway config中使用的sleep + lock命令导致的gpg无效的PIN输入tty引起的

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock'"

或只是睡眠/暂停

重置引脚输入tty以解决问题

gpg-connect-agent updatestartuptty /bye > /dev/null

和我摇摆的sleep + lock命令的修复方法:

bindsym $mod+Shift+l exec "sh -c 'gpg-connect-agent reloadagent /bye>/dev/null; systemctl suspend; swaylock; gpg-connect-agent updatestartuptty /bye > /dev/null'"


1
谢谢。几天前我遇到了这个问题,我在使用gpg的同时gpg-connect-agent updaterstartuptty /bye > /dev/null对〜/ .zshrc 进行了评论,取消注释此行就解决了我的问题。
J.Adler '19

4

对于此错误:

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

谢谢。


2

出现SSH错误的原因可能有多种:

sign_and_send_pubkey:签名失败:代理拒绝操作

其中一些可能与其他答案(请参见本主题答案)突出显示的问题有关,其中一些可能被隐藏,因此需要进行更深入的调查。

就我而言,我收到以下错误消息:

sign_and_send_pubkey:签名失败:代理拒绝操作

user@website.domain.com:权限被拒绝(公钥,gssapi-keyex,gssapi-with-mic)

找到真正问题的唯一方法是调用-v verbose选项,这会导致打印大量调试信息:

debug1: Connecting to website.domain.com [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa.website.domain.com-cert type -1

请注意,该行key_load_public: No such file or directory是指下一行而不是前一行。

因此SSH真正说的是它找不到命名的公用密钥文件id_rsa.website.domain.com-cert,在我的情况下这似乎是问题所在,因为我的公用密钥文件不包含-cert后缀。

长话短说:我的解决方法是确保公钥文件的命名符合预期。如果没有调试连接,我绝对不会怀疑。

最重要的是使用SSH详细模式(-v选项)来找出问题所在,可能有多种原因,在这个/另一个线程上找不到任何原因。


0

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

是的,我在MacOSX SourceTree中有完全相同的错误,但是在iTerm2终端中,一切正常。

但是,问题似乎是我有两个 ssh-agent正在运行;(

首先运行/usr/bin/ssh-agent(又名MacOSX),然后/usr/local/bin/ssh-agent运行HomeBrew 。

从SourceTree启动一个终端SSH_AUTH_SOCK,使用lsof发现两个不同的ssh-agents ,使我能够看到的差异,然后能够将键(使用ssh-add)加载到系统的默认值ssh-agent(即/usr/bin/ssh-agent)中,SourceTree再次正常工作。


0

是。在客户端计算机上运行ssh-add。然后重复命令 ssh-copy-id userserver@012.345.67.89


0

对我而言,问题在于将公钥复制/粘贴到Gitlab中的方式不正确。该副本产生了额外的回报。确保粘贴的是单行密钥。


0

我也有一个sign_and_send_pubkey: signing failed: agent refused operation错误。但就我而言,问题是一条错误的pinentry道路。

在我看来${HOME}/.gnupg/gpg-agent.confpinentry-program地产指向一条古老的小路。更正那里的路径并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


0

在我的情况下,问题是GNOME密钥环持有要使用的ssh密钥的无效密码。在花费了可观的时间进行故障排除后,我运行seahorse并找到了保留空字符串的条目。我只能猜测,这是由于在较早的时候第一次使用时弄错了密码短语,然后为了取消后退至命令行而可能取消了请求者。使用正确的密码更新条目可以立即解决该问题。删除该条目(从“登录”密钥环)并在第一个提示处重新输入密码(并选中相应的复选框)也可以解决此问题。现在,代理从名为“ login”的登录密钥环上未锁定的位置获取正确的密码,并且不再要求输入密码或“拒绝操作”。当然是YMMV。


0

在这里起作用的是:在客户端上

1)SSH添加

2)ssh-copy-id user @ server

密钥是在前一段时间用普通的“ ssh-keygen -t rsa”创建的,我切换了错误消息,因为我从客户端到服务器(通过ssh-id-copy)将ssh公用密钥复制到了服务器,而没有先运行ssh-add,因为我错误地认为我早些时候添加了它们。


0

对于最近升级到“现代” ssh版本[OpenSSH_8.1p1,OpenSSL 1.1.1d FIPS 2019年9月10日]的人的快速说明-随fedora 31一起提供,似乎不再接受旧的DSA SHA256密钥(我的版本是2006年!)-创建了一个新的rsa密钥,将其公共添加到授权中,将其私有添加到客户端上,并且一切正常。

感谢您之前的建议,尤其是ssh -v非常有用

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.