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

时间:2017-05-29 20:36:24

标签: ssh remote-access digital-ocean ssh-keys

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

17 个答案:

答案 0 :(得分:107)

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

ssh-add -l(再次在客户端上)确认确实已添加。

答案 1 :(得分:30)

将Fedora 26升级到28后,我遇到了同样的问题。 并且缺少以下日志

/var/log/secure
/var/log/messages

<强> ISSUE:

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

答案 2 :(得分:24)

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

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

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

要更改文件权限,请使用

chmod 600 id_rsa
chmod 644 id_rsa.pub

这解决了我的更新问题。

答案 3 :(得分:6)

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

对我有用。

chmod 600 ~/.ssh/id_rsa

答案 4 :(得分:1)

出现此错误:

# 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帐户中验证或再次添加公钥&gt;个人资料&gt; 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.

谢谢。

答案 5 :(得分:1)

将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

以及针对我的sway 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'"

答案 6 :(得分:0)

我也遇到了sign_and_send_pubkey: signing failed: agent refused operation错误。但就我而言,问题是错误的pinentry路径。

在我的${HOME}/.gnupg/gpg-agent.conf中,pinentry-program属性指向一个古老的pinentry路径。更正那里的路径并重新启动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

答案 7 :(得分:0)

第一 ssh-add 然后 ssh user@ip

这对我有用

答案 8 :(得分:0)

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

如果您使用的是SSH with Smart Card (PIV),并使用
将卡添加到ssh-agent ssh-add -s /usr/lib64/pkcs11/opensc-pkcs11.so
您可能会得到错误
sign_and_send_pubkey: signing failed: agent refused operation
如果PIV身份验证已过期,或者您已卸下并重新插入PIV卡,则从ssh进行操作。

在这种情况下,如果您尝试再做一次ssh-add -s,仍然会收到错误消息:
Could not add card "/usr/lib64/opensc-pkcs11.so": agent refused operation

根据RedHat Bug 1609055 - pkcs11 support in agent is clunky,您需要这样做

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

答案 9 :(得分:0)

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

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

答案 10 :(得分:0)

这里有效的方法:在客户端上

1)ssh-add

2)ssh-copy-id user @ server

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

答案 11 :(得分:0)

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

答案 12 :(得分:0)

我需要分享,因为我花了太多时间寻找解决方案

  

这是解决方案:https://unix.stackexchange.com/a/351742/215375

我正在使用此命令:

ssh-keygen -o -t rsa -b 4096 -C "email@example.com"

gnome-keyring不支持生成的密钥。

删除-o参数解决了这个问题。

答案 13 :(得分:0)

对我来说,问题是公钥向Gitlab中的错误复制/粘贴。该副本产生了额外的回报。确保粘贴的是单行密钥。

答案 14 :(得分:0)

可能会有各种原因导致SSH错误:

  

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

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

对于我来说,我收到以下错误消息:

  

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

     

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

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

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选项)来找出问题所在,可能有多种原因,在这个/另一个线程上找不到任何原因。

答案 15 :(得分:0)

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

答案 16 :(得分:-1)

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

对,我在MacOSX SourceTree中有完全相同的错误,但是,在iTerm2终端内,事情只是花花公子。

然而,问题似乎是我已经两个 ssh-agent正在运行;(

第一个是/usr/bin/ssh-agent(又名MacOSX),然后是HomeBrew安装/usr/local/bin/ssh-agent正在运行。

从SourceTree中启动终端,让我看到SSH_AUTH_SOCK中的差异,使用lsof我找到了两个不同的ssh-agent,然后我就可以加载密钥了(使用ssh-add)进入系统的默认ssh-agent(即/usr/bin/ssh-agent),SourceTree再次运行。