用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"没有返回任何内容。
正如其他人所提到的，这个错误可能有多种原因。
如果您正在使用SSH with Smart Card (PIV)，并将该卡添加到SSH -agent with
Ssh-add -s /usr/lib64/pkcs11/opensc-pkcs11.so
你可能会得到错误
Sign_and_send_pubkey:签名失败:代理拒绝操作
如果PIV身份验证已经过期，或者如果您已经移除并重新插入PIV卡，则从ssh登录。
在这种情况下，如果你尝试执行另一个ssh-add -s，你仍然会得到一个错误:
无法添加卡片"/usr/lib64/opensc-pkcs11。所以:代理拒绝操作
根据RedHat Bug 1609055 - pkcs11在代理中的支持是笨拙的，你反而需要做
ssh-add -e /usr/lib64/opensc-pkcs11.so
ssh-add -s /usr/lib64/opensc-pkcs11.so
导致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选项)来找出哪里出了问题，可能有各种原因，在这个/另一个线程上找不到任何原因。
