Como resolver “sign_and_send_pubkey: falha na assinatura: operação recusada pelo agente”?

Configurando uma nova gota Digital Ocean com chaves SSH. Quando eu executo ssh-copy-idisto é o que obtenho:

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.

No entanto, quando tento entrar no ssh, isso acontece:

ssh user@012.345.67.89
sign_and_send_pubkey: signing failed: agent refused operation
user@012.345.67.89's password: 

Ao inserir a senha, estou conectado perfeitamente, mas isso, obviamente, vai contra o propósito de criar a chave SSH em primeiro lugar. Decidi dar uma olhada no lado do servidor do agente ssh e aqui está o que recebo:

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 também contém uma entrada de chave ssh-rsa, mas find -name "keynamehere"não retorna nada.

Execute ssh-addna máquina cliente, que adicionará a chave SSH ao agente.

Confirme com ssh-add -l(novamente no cliente) se ele foi realmente adicionado.

Depois de atualizar o Fedora 26 para o 28, enfrentei o mesmo problema. E os seguintes registros estavam faltando

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

QUESTÃO:

antop@localmachine  ~  ssh root@ocp1.example.com
sign_and_send_pubkey: signing failed: agent refused operation
root@ocp1.example.com's password:

mensagem de erro não está apontando o problema real. Problema resolvido por

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

Eu estava tendo o mesmo problema no Linux Ubuntu 18 . Após a atualização do Ubuntu 17.10 , cada comando git mostraria essa mensagem.

A maneira de resolver isso é verificar se você tem a permissão correta no id_rsae id_rsa.pub.

Verifique o número chmod atual usando stat --format '%a' <file>. Deve ser 600 para id_rsa e 644 para id_rsa.pub.

Para alterar a permissão nos arquivos use

chmod 600 id_rsa
chmod 644 id_rsa.pub

Isso resolveu meu problema com a atualização.

Execute o comando abaixo para resolver esse problema.

Funcionou para mim

chmod 600 ~/.ssh/id_rsa

Tive o erro ao usar o gpg-agent como meu ssh-agent e usar uma subchave gpg como minha chave ssh https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .

Eu suspeito que o problema foi causado por ter uma entrada de pin inválida tty para gpg causada pelo meu comando sleep + lock usado em minha configuração de balanço

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

ou apenas dormir / suspender

Redefina a entrada de pin tty para corrigir o problema

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

e a correção para o meu comando 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'"

Para este erro:

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

Verifique ou adicione novamente a chave pública na conta Github> perfil> ssh.

Eu resolvi assim:

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

Obrigado.

Pode haver vários motivos para a obtenção do erro SSH:

sign_and_send_pubkey: a assinatura falhou: o agente recusou a operação

Alguns deles podem estar relacionados aos problemas destacados pelas outras respostas (veja as respostas deste tópico), alguns deles podem estar ocultos e, portanto, exigiriam uma investigação mais detalhada.

No meu caso, recebo a seguinte mensagem de erro:

sign_and_send_pubkey: a assinatura falhou: o agente recusou a operação

usuário@website.domain.com: permissão negada (publickey, gssapi-keyex, gssapi-with-mic)

A única maneira de encontrar o problema real era invocar a opção -v verbose que resultou na impressão de muitas informações de depuração:

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

Observe que a linha que diz key_load_public: No such file or directoryse refere à próxima linha e não à linha anterior.

Portanto, o que o SSH realmente diz é que não foi possível encontrar o arquivo de chave pública denominado id_rsa.website.domain.com-certe esse parecia ser o problema no meu caso, já que meu arquivo de chave pública não continha o -certsufixo.

Resumindo: a correção no meu caso foi apenas garantir que o arquivo de chave pública fosse nomeado conforme o esperado. Eu nunca poderia suspeitar disso sem depurar a conexão.

O resultado final é USE O MODO SSH VERBOSE (opção -v) para descobrir o que está errado. Pode haver vários motivos, nenhum que possa ser encontrado neste / outro tópico.

Esta deve ser uma questão de superusuário.

Certo, eu tenho exatamente o mesmo erro dentro do MacOSX SourceTree, no entanto, dentro de um terminal de iTerm2, as coisas funcionam perfeitamente.

No entanto, o problema parecia ser que eu tinha dois ssh-agent segundos em execução; (

O primeiro sendo /usr/bin/ssh-agent(também conhecido como MacOSX's) e depois também o HomeBrew instalado /usr/local/bin/ssh-agentrodando.

Ativar um terminal do SourceTree me permitiu ver as diferenças em SSH_AUTH_SOCK, usando lsof, encontrei os dois se diferentes ssh-agentse consegui carregar as chaves (usando ssh-add) no padrão do sistema ssh-agent(ou seja. /usr/bin/ssh-agent), SourceTree estava funcionando novamente.

Sim. Execute ssh-add na máquina cliente. Em seguida, repita o comando ssh-copy-id userserver@012.345.67.89

Para mim, o problema era copiar / colar incorretamente a chave pública no Gitlab. A cópia gerou um retorno extra. Certifique-se de que o que você colar é uma chave de uma linha.

Também recebi um sign_and_send_pubkey: signing failed: agent refused operationerro. Mas no meu caso o problema foi um pinentrycaminho errado .

Na minha ${HOME}/.gnupg/gpg-agent.confa pinentry-programpropriedade apontava para um antigo caminho de pinentaria. Corrigindo o caminho ali e reiniciando o gpg-agentconsertou pra mim.

Eu descobri seguindo os logs com journalctl -f. Lá onde as linhas de registro, como a seguinte, contêm o caminho errado:

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

Preciso compartilhar, pois passei muito tempo procurando uma solução

Aqui estava a solução: https://unix.stackexchange.com/a/351742/215375

Eu estava usando este comando:

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

gnome-keyring não suporta a chave gerada.

Remover o -oargumento resolveu o problema.

No meu caso, o problema era que o chaveiro do GNOME estava contendo uma senha inválida para a chave ssh a ser usada. Depois de gastar uma quantidade indecente de tempo resolvendo esse problema, corri seahorsee encontrei a entrada para conter a string vazia. Só posso supor que foi causado por erro de digitação da frase secreta no primeiro uso algum tempo antes e, em seguida, provavelmente cancelando o solicitante ou algo assim para retornar à linha de comando. Atualizar a entrada com a senha correta resolveu o problema imediatamente. Excluir essa entrada (do chaveiro de "login") e inserir novamente a frase-senha no primeiro prompt (e marcar a caixa de seleção apropriada) resolve isso também. Agora o agente obtém a frase secreta correta do chaveiro desbloqueado no login denominado "login" e não pede mais a frase secreta nem "recusa a operação" mais. Claro YMMV.

O que funcionou aqui: no cliente

1) ssh-add

2) ssh-copy-id usuário @ servidor

As chaves foram criadas há algum tempo com "ssh-keygen -t rsa" simples. Troquei a mensagem de erro porque copiei minha chave pública ssh do cliente para o servidor (com ssh-id-copy) sem executar o ssh-add primeiro, já que eu erroneamente assumi que os tinha adicionado algum tempo antes.

observação rápida para aqueles que atualizaram recentemente para a versão ssh "moderna" [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 de setembro de 2019] - fornecido com o fedora 31, parece não estar mais aceitando chaves DSA SHA256 antigas (as minhas são datadas de 2006!) - criou uma nova chave rsa, pública adicionada a autorizada, privada no cliente e tudo funciona perfeitamente.

obrigado pelas sugestões anteriores, especialmente o ssh -v foi muito útil