Configuring a new Digital Ocean droplet with SSH keys. When I run ssh-copy-id this is what I get:

使用SSH密钥配置新的数字海洋水滴。当我运行ssh-Copy-id时，我得到的是：

ssh-copy-id [email protected]
/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
[email protected]'s password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.

However, when I then attempt to ssh in, this happens:

但是，当我随后尝试ssh时，发生了以下情况：

ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password: 

Upon entering the password, I am logged in just fine, but this of course defeats the purpose of creating the SSH key in the first place. I decided to take a look at the ssh-agent server-side and here's what I get:

输入密码后，我就可以正常登录了，但这当然违背了创建SSH密钥的初衷。我决定看看ssh-agent服务器端，这是我得到的：

[email protected]:~# eval `ssh-agent -s`
Agent pid 5715
[email protected]:~# ssh-add -l
The agent has no identities.

user/.ssh/authorized_keys does contain an ssh-rsa key entry, as well, but find -name "keynamehere" returns nothing.

用户/.ssh/AuthorizedKey也包含ssh-rsa密钥条目，但find-name“keynamehere”不返回任何内容。

优秀答案推荐

Run ssh-add on the client machine, that will add the SSH key to the agent.

在客户机上运行ssh-Add，这会将SSH密钥添加到代理。

Confirm with ssh-add -l (again on the client) that it was indeed added.

使用ssh-Add-L(同样在客户机上)确认它确实已添加。

After upgrading Fedora 26 to 28 I faced same issue.
And following logs were missing

在将Fedora 26升级到28之后，我遇到了同样的问题。并且以下日志丢失

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

ISSUE:

问题：

antop@localmachine  ~  ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password:

error message is not pointing actual issue. Issue resolved by

错误消息不指向实际问题。问题的解决方式

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

I was having the same problem in Linux Ubuntu 18. After the update from Ubuntu 17.10, every git command would show that message.

我在Linux Ubuntu 18上也遇到了同样的问题。在Ubuntu 17.10更新后，每个git命令都会显示这一消息。

The way to solve it is to make sure that you have the correct permission on the id_rsa and id_rsa.pub.

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

Check the current chmod number by using stat --format '%a' <file>.
It should be 600 for id_rsa and 644 for id_rsa.pub.

使用stat--格式‘%a’<文件>检查当前的chmod编号。Id_rsa应该是600，id_rsa.pub应该是644。

To change the permission on the files use

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

chmod 600 id_rsa
chmod 644 id_rsa.pub

That solved my issue with the update.

这解决了我的更新问题。

Run the below command to resolve this issue.

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

It worked for me.

这对我很管用。

chmod 600 ~/.ssh/id_rsa

I once had a problem just like yours, and this is how I solved it through the following steps.

我曾经遇到过一个和你一样的问题，这就是我如何通过以下步骤解决它的。

1. chmod 700 ~/.ssh


2. chmod 600 ~/.ssh/*


3. ssh-copy-id user@ip


4. ssh-agent -s


5. ssh-add

I had the error when using gpg-agent as my ssh-agent and using a gpg subkey as my ssh key https://wiki.archlinux.org/index.php/GnuPG#gpg-agent.

在使用gpg-https://wiki.archlinux.org/index.php/GnuPG#gpg-agent.作为ssh代理并使用gpg子密钥作为ssh密钥代理时，我遇到了这个错误。

I suspect that the problem was caused by having an invalid pin entry tty for gpg caused by my sleep+lock command used in my sway config

我怀疑这个问题是由于在Sway配置中使用了睡眠+锁定命令而导致gpg的PIN条目tty无效所致

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

Bindsym$mod+Shift+L执行“sh-c‘gpg-CONNECT-AGENT RELOADACT/BYE>/dev/NULL；systemctl Suspend；swaylock’”

or just the sleep/suspend

或者仅仅是睡眠/暂停

Reset the pin entry tty to fix the problem

重置PIN条目TTY以修复问题

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

GPG-CONNECT-AGENT updatestartuptty/再见>/dev/空

and the fix for my sway sleep+lock command:

我的摇摆睡眠+锁定命令的修复方法是：

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

Bindsym$mod+Shift+L执行“sh-c‘gpg-CONNECT-AGENT重新加载代理/BYE>/dev/NULL；systemctl Suspend；swaylock；gpg-CONNECT-AGENT updatestartuptty/BYE>/dev/NULL’”

eval "$(ssh-agent -s)"

To first start the ssh agent

Eval“$(ssh-agent-S)”以首先启动ssh代理

ssh-add

To then add the ssh key

SSH-添加，然后添加ssh密钥

To this error:

对于此错误：

# git pull
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]: Permission denied (publickey).    
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

Verify or add again the public key in Github account > profile > ssh.

I solved like this:

我是这样解决的：

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

Thank you.

谢谢。

There could be various reason for getting the SSH error:

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

sign_and_send_pubkey: signing failed: agent refused operation

Some of them could be related to the issues highlighted by the other answers (see this thread answers), some of them could be hidden and thus would require a closer investigation.

其中一些可能与其他答案所强调的问题有关(请参阅此帖子答案)，其中一些可能是隐藏的，因此需要进行更仔细的调查。

In my case I've got the following error message:

在我的例子中，我收到了以下错误消息：

sign_and_send_pubkey: signing failed: agent refused operation

[email protected]: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

The only way to find the real problem was to invoke the -v verbose option which resulted in printing a lot of debugging info:

找到真正问题的唯一方法是调用-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

Please note that the line saying key_load_public: No such file or directory is referring the next line and not the previous line.

请注意，行KEY_LOAD_PUBLIC：没有这样的文件或目录引用的是下一行，而不是前一行。

So what SSH really says is that it could not find the public key file named id_rsa.website.domain.com-cert and that seemed to be the problem in my case since my public key file did not contain the -cert suffix.

所以SSH实际上说的是它找不到名为id_rsa.website.domain.com-cert的公钥文件，这似乎就是我的问题所在，因为我的公钥文件不包含-cert后缀。

Long story short: the fix in my case was just to make sure that the public key file was named as expected. I could never suspected that without debugging the connection.

长话短说：在我的案例中，修复方法只是确保公钥文件按预期命名。如果不调试连接，我永远不会怀疑这一点。

The bottom line is USE THE SSH VERBOSE MODE (-v option) to figure out what is wrong, there could be various reasons, none that could be found on this/another thread.

底线是使用SSH详细模式(-v选项)来找出错误所在，可能有各种原因，在这个/另一个线程中找不到任何原因。

First
ssh-add
then
ssh user@ip

首先使用ssh-add，然后使用ssh user@ip

this worked for me

这对我很管用

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.

在我的例子中，问题是GNOME KEYRING持有要使用的ssh密钥的无效密码短语。在花费了大量的时间来解决这个问题之后，我运行了海马，发现条目持有空串。我只能猜测，这是由于在一段时间之前输入了错误的密码短语，然后可能为了退回到命令行而取消了请求者之类的内容。使用正确的密码更新条目立即解决了该问题。删除该条目(从“登录”密钥环)并在第一个提示下重新输入密码短语(并选中相应的复选框)也可以解决这个问题。现在，代理从名为“LOGIN”的已解锁的登录密钥环中获得正确的密码短语，并且不再要求密码短语或“拒绝操作”。当然是YMMV。

Beware of how you name your ssh key files

注意如何命名ssh密钥文件

If you have more than one key pair, you may be using ssh-keygen with the -f <key name> to name the output files. In my case, I was naming my keys like username@organization and [email protected], which helps to keep multiple key pairs organized.

如果您有多个密钥对，则可以使用带有-f 的ssh-keygen来命名输出文件。在我的例子中，我将我的密钥命名为用户名@组织和[电子邮件受保护]，这有助于保持多个密钥对的组织。

The problem is that the ssh agent doesn't like the @ character.

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

In my case this was causing the sign_and_send_pubkey: signing failed: agent refused operation error, and was preventing the session keyring to interact with the ssh agent.

在我的例子中，这会导致Sign_and_Send_pubkey：签名失败：代理拒绝操作错误，并阻止会话密钥环与ssh代理交互。

Renaming my key files to username_at_organization fixed the problem.

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

Yes. Run ssh-add on the client machine.
Then repeat command ssh-copy-id [email protected]

是。在客户机上运行ssh-Add。然后重复命令ssh-Copy-id[电子邮件受保护]

I got a sign_and_send_pubkey: signing failed: agent refused operation error as well. But in my case the problem was a wrong pinentry path.

我收到Sign_and_Send_pubkey：签名失败：代理拒绝操作错误。但在我的案例中，问题是一条错误的拼接路径。

In my ${HOME}/.gnupg/gpg-agent.conf the pinentry-program property was pointing to an old pinentry path. Correcting the path there and restarting the gpg-agent fixed it for me.

在我的${home}/.gnupg/gpg-agent.conf中，pinentry-Program属性指向一个旧的Pinentry路径。更正那里的路径并重新启动gpg-agent为我修复了它。

I discovered it by following the logs with journalctl -f. There where log lines like the following containing the wrong path:

我通过使用Jouralctl-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

According to Github security blog RSA keys with SHA-1 are no longer accepted.

根据Github安全博客，带有SHA-1的RSA密钥不再被接受。

Use the following command to create new SSH key with ECDSAencryption and add it to Github.

使用以下命令创建带有ECDSA加密的新SSH密钥，并将其添加到Github。

ssh-keygen -t ecdsa -b 521 -C "[email protected]"

SSH-keygen-t ecdsa-b 521-C“[电子邮件受保护]”

original answer with details can be found here

提供详细信息的原始答案可在此处找到

This should be rather a SuperUser question.

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

Right I have the exact same error inside MacOSX SourceTree, however, inside a iTerm2 terminal, things work just dandy.

是的，我在MacOSX SourceTree中遇到了完全相同的错误，然而，在iTerm2终端中，事情运行得很好。

However, the problem seemed to be that I've got two ssh-agents running ;(

然而，问题似乎是我有两个ssh代理在运行；

The first being /usr/bin/ssh-agent (aka MacOSX's) and then also the HomeBrew installed /usr/local/bin/ssh-agent running.

第一个是/usr/bin/ssh-agent(又名MacOSX)，然后是安装的自制软件/usr/local/bin/ssh-agent。

Firing up a terminal from SourceTree, allowed me to see the differences in SSH_AUTH_SOCK, using lsof I found the two different ssh-agents and then I was able to load the keys (using ssh-add) into the system's default ssh-agent (ie. /usr/bin/ssh-agent), SourceTree was working again.

从SourceTree启动一个终端，使我能够看到SSH_AUTH_SOCK中的差异，使用lsof我找到了两个不同的ssh代理，然后我能够将密钥(使用ssh-add)加载到系统的默认ssh-agent(即。/usr/bin/ssh-agent)，SourceTree再次正常工作。

For me the problem was a wrong copy/paste of the public key into Gitlab. The copy generated an extra return. Make sure what you paste is a one-line key.

对我来说，问题是将公钥错误地复制/粘贴到GitLab中。这份副本产生了额外的回报。确保粘贴的是单行键。

I need to share, as I spent too much time looking for a solution

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

Here was the solution : https://unix.stackexchange.com/a/351742/215375

I was using this command :

我使用的是以下命令：

ssh-keygen -o -t rsa -b 4096 -C "[email protected]"

gnome-keyring does not support the generated key.

GNOME-KEYRIN不支持生成的密钥。

Removing the -o argument solved the problem.

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

What worked here : on the client

在这里起作用的是：在客户端

1) ssh-add

1)ssh-add.

2) ssh-copy-id user@server

2)ssh-Copy-id用户@服务器

The keys has been created some time ago with plain "ssh-keygen -t rsa"
I sw the error message because I copied across my ssh public key from client to server (with ssh-id-copy) without running ssh-add first, since I erroneously assumed I'd added them some time earlier.

这些密钥是在一段时间前用简单的“ssh-keygen-t rsa”创建的，因为我在没有先运行ssh-add的情况下从客户机向服务器复制了我的ssh公钥(使用ssh-id-Copy)，因为我错误地认为我在一段时间之前已经添加了它们。

quick note for those recently upgrading to "modern" ssh version [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 Sep 2019] - supplied with fedora 31, seems not to be anymore accepting old DSA SHA256 keys (mine are dated 2006!) - created a new rsa key, public added to authorized, private on client, and everything works perfectly.

对于那些最近升级到“现代”ssh版本[OpenSSH_8.1p1，OpenSSL1.1.1d FIPS 2019年9月10日]-随Feddora 31提供，似乎不再接受旧的DSA SHA256密钥(我的密钥是2006年！)-创建了一个新的RSA密钥，公共密钥添加到授权的，客户端的私有的，一切都运行得很好。

thanks for previous suggestions, especially the ssh -v has been very useful

感谢您之前的建议，特别是ssh-v非常有用。

As others have mentioned, there can be multiple reasons for this error.

正如其他人提到的那样，造成这种错误的原因可能有多种。

If you are using SSH with Smart Card (PIV), and adding the card to ssh-agent with

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

you may get the error

sign_and_send_pubkey: signing failed: agent refused operation

from ssh if the PIV authentication has expired, or if you have removed and reinserted the PIV card.

如果您将SSH与智能卡(PIV)一起使用，并使用ssh-Add-S/usr/lib64/pkcs11/opensc-pkcs11将该卡添加到ssh-agent，则您可能会收到错误sign_and_end_pubkey：签名失败：如果PIV身份验证已过期，或如果您已卸下并重新插入PIV卡，则代理拒绝从ssh执行操作。

In that case, if you try to do another ssh-add -s you will still get an error:

Could not add card "/usr/lib64/opensc-pkcs11.so": agent refused operation

在这种情况下，如果您尝试执行另一次ssh-Add-S，您仍然会得到一个错误：Can‘t Add Card“/usr/lib64/opensc-pkcs11.so”：代理拒绝操作

According to RedHat Bug 1609055 - pkcs11 support in agent is clunky, you instead need to do

根据RedHat Bug 1609055-PKCS11在代理中的支持是笨拙的，相反，您需要做

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

Another reason for this is OpenSSH v9.0's new default of NTRU primes + x25519 key exchange, in combination with gpg-agent (at least, as at v2.2.32).

另一个原因是OpenSSHv9.0‘S新默认的NTRU素数+x25519密钥交换，与GPG-AGENT(至少，如v2.2.32)相结合。

To work-around, disable the new key exchange algortihm (and thus it's security benefit) thus:

要解决此问题，请禁用新的密钥交换算法(以及它的安全优势)，如下所示：

ssh -o 'KexAlgorithm [email protected]' [...]

(or the same in SSH config.)

(或在SSH配置中相同。)

cf. https://unix.stackexchange.com/questions/701131/use-ntrux25519-key-exchange-with-gpg-agent

参见Https://unix.stackexchange.com/questions/701131/use-ntrux25519-key-exchange-with-gpg-agent

This could cause by 1Passsword not support ssh-rsa key exchange. They support newer rsa-sha-512 and rsa-sha-256 with security considerations.

这可能会导致1Password不支持SSH-RSA密钥交换。出于安全考虑，它们支持较新的RSA-SHA-512和RSA-SHA-256。

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

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

Just to toss another cause into the ring...

只是为了把另一项事业扔进拳击场。

My env was configured to use a Gemalto card...but I had an old keypair named id_rsa_gemalto_old(.pub) in my ~/.ssh/ and that -- having gemalto in the name -- was enough for git fetch to result in sign_and_send_pubkey: signing failed: agent refused operation.

我的env被配置为使用Gemalto卡……但我的~/.ssh/中有一个名为id_rsa_Gemalto_old(.pub)的旧密钥对，并且在名称中包含Gemalto，足以让Git FETCH产生Sign_and_Send_pubkey：Signing Failure：代理拒绝操作。

(Ubuntu 18.04.6)

(Ubuntu 18.04.6)

If you changed the crypto policy to allow SHA1 after the agent was loaded (with something like update-crypto-policies --set LEGACY) and the remote host uses SHA1, then the agent needs to be reloaded:

如果您在加载代理后更改了加密策略以允许SHA1(使用类似更新加密策略--设置传统的内容)，并且远程主机使用SHA1，则需要重新加载代理：

kill $SSH_AGENT_PID
eval $(ssh-agent)
ssh-add

I just solved it in a strange way. Would like someone to update this answer and explain why.

我只是用一种奇怪的方式解决了这个问题。希望有人更新此答案并解释原因。

I was getting the error after ssh from ubuntu 18 to a server with Ubuntu 18.
All permissions are correct.
Pub key is added to the server
SSH key pair is valid, because the below command reported the fingerprint.

在从ubuntu 18向安装了ubuntu 18的服务器执行ssh之后，我收到了错误消息。所有权限都是正确的。PUB密钥添加到服务器SSH密钥对是有效的，因为下面的命令报告了指纹。

ssh-keygen -l -f ~/.ssh/id_rsa.pub

I opened ~/.ssh/id_rsa.pub and changed a random character in the middle of the key.

我打开~/.ssh/id_rsa.pub并在密钥中间更改了一个随机字符。

ssh-keygen reported the pub key remains valid.

SSH-KEYGEN报告PUB密钥仍然有效。

Now I can login just by ssh to server, no other modification needed.

现在我可以只通过ssh登录到服务器，不需要其他修改。