用SSH密钥配置一个新的数字海洋液滴。当我运行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.
用户/。Ssh /authorized_keys也包含Ssh -rsa密钥条目，但是find name "keynamehere"没有返回任何内容。
我得到了一个sign_and_send_pubkey: signing failed: agent refused操作错误。但在我的案例中，问题是错误的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
导致SSH错误的原因有很多:
Sign_and_send_pubkey:签名失败:代理拒绝操作
其中一些问题可能与其他答案所强调的问题有关(请参阅此线程的答案)，其中一些问题可能被隐藏，因此需要更仔细的调查。
在我的情况下，我得到了以下错误消息:
Sign_and_send_pubkey:签名失败:代理拒绝操作
user@website.domain.com:权限被拒绝(publickey, gsapi -keyex, gsapi -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或directory指的是下一行，而不是上一行。
因此，SSH真正说的是，它无法找到名为id_rsa.website.domain.com-cert的公钥文件，这似乎是我的情况下的问题，因为我的公钥文件不包含-cert后缀。
长话短说:在我的案例中，修复只是确保公钥文件按预期命名。如果不调试连接，我绝不会怀疑这一点。
底线是使用SSH VERBOSE模式(-v选项)来找出哪里出了问题，可能有各种原因，在这个/另一个线程上找不到任何原因。
