Ubuntu 16.04 ssh: sign_and_send_pubkey: assinatura falhou: agente recusou operação

173

Acabei de atualizar meu sistema Ubuntu de 15.10 para 16.04 limpando completamente a partição Ubuntu 15 do meu sistema.

Depois de instalar o Ubuntu 16.04, recriei minhas chaves ssh quando esqueci de fazer o backup delas, mas sempre que tento usá-las, sign_and_send_pubkey: signing failed: agent refused operationisso é um pouco irritante, pois me permite acessar meu servidor ssh, mas o git se recusa a enviar códigos usando ssh.

Eu já enviei as chaves para o servidor usando ssh-copy-id.

O servidor ao qual estou me conectando é um servidor Ubuntu 16.04 atualizado por meio do do-release-upgradecomando Qualquer ajuda será muito apreciada.

Gamerb
fonte

Respostas:

315

Parece que um ssh-agentjá está em execução, mas não encontra nenhuma chave anexada. Para resolver isso, adicione as identidades da chave privada ao agente de autenticação da seguinte maneira:

ssh-add

Então você pode sshentrar no seu servidor.

Além disso, você pode ver a lista de impressões digitais de todas as identidades atualmente adicionadas por:

ssh-add -l
Ron
fonte
não é -1 (número <one>), é -l (L minúsculo) no seu segundo comando
Daniel Alder
3
@ Daniel Alder É realmente minúsculas l.
Ron
Você está certo, desculpe. O problema é as letras minúsculas Lda fonte "Liberation Mono" :-(
Daniel Alder
1
Eu não acho que você deva usar ssh-addoutro que não seja ssh-add -lporque você pode acabar com muitas entradas no arquivo ssh-agent. Não há necessidade de adicionar manualmente. Dash > Startup Applicationsmostra que ssh-agentjá está em execução e detectará automaticamente os arquivos como ~/.ssh/id_rsae ~/.ssh/id_rsa.pub. Para provar isso, você pode usar ssh-add -lantes e depois do uso ssh-keygen. Você verá que ele monitora os arquivos para que você não precise adicioná-los manualmente.
H2ONaCl 26/01
1
Da mesma forma, não use ssh-add -de ssh-add -Dexecute a exclusão manual. Basta apagar os arquivos de chave ~/.ssh/id_rsae ~/.ssh/id_rsa.pube o ssh-agentaviso de vontade. Para provar que você pode fazer ssh-add -lantes e depois de excluir os arquivos de chave.
H2ONaCl 26/01
57

Solução Simples

Eu tive o mesmo problema no Ubuntu 18.04. Isso é tudo sobre permissões de chave privada do lado do cliente .

$ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation

As permissões do arquivo estavam muito abertas (0644).

O seguinte comando resolveu:

chmod 600 ~/.ssh/id_rsa
Antonio Feitosa
fonte
2
O caminho deve ser absoluto assim: chmod 600 ~ / .ssh / id_rsa para fazê-lo funcionar em todos os casos.
Omar Alahmed
54

Eu tive o mesmo problema (mesmos sintomas)

sam@xxxxx:~/.ssh$ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

... mas a solução foi diferente.

O problema estava vindo do uso do GNOME-KEYRING. O post referente à solução pode ser lido aqui .

Em resumo:

  1. Detecte o problema adicionando SSH_AUTH_SOCK = 0 na frente do comando ssh. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh [email protected]
  2. Caso consiga se conectar. Abra o aplicativo StartUp Application (usando a função de pesquisa da área de trabalho, por exemplo) e desative o uso do gnome-keyring.
  3. Reiniciar

A página fornece outros detalhes em caso de problema semelhante com solução diferente.

sam
fonte
24
Sua solução meio que funcionou para mim (problema diferente com sintomas semelhantes). Usando a etapa 1, recebi a mensagem de erro Permissions 0775 for '.ssh/id_rsa' are too open. A solução simples aqui foi chmod 600 .ssh/id_rsa.
26418 Matt
1
Isso também ajuda a depurar não apenas a conexão do shell ssh, mas também o git ssh auth. Usei esse comando SSH_AUTH_SOCK=0antes git pulle recebi permissões como Matt.
Serge
Trabalhou para mim também. Aparentemente, o motivo foi que eu mudei comentário na minha chave e muito provavelmente o agente chaveiro gnome (aka cavalo marinho) ainda estava mantendo a versão antiga na memória
maoizm
18

Quando eu estava sign_and_send_pubkey: signing failed: agent refused operationentrando em vários servidores, li a resposta do VonC no Stack Overflow para obter mais informações sobre bugs relacionados, a solução para mim foi remover o gnome-keyring, excluir identidades do ssh-agent e reiniciar.

sudo apt-get autoremove gnome-keyring
ssh-add -D

Então todas as minhas chaves começaram a funcionar perfeitamente.

ATUALIZAR:

Solução temporária sem desinstalar o chaveiro

Se você quiser manter o gnome-keyring e tiver o agent refused operationerro, use:

eval `ssh-agent -s`
ssh-add

ou use SSH_AUTH_SOCK=0 ssh your-server

A solução permanente sem desinstalar o chaveiro

Se você puder, o gnome-keyring é compatível com a chave RSA de 4096 bits, então apenas gere uma nova chave com:

ssh-keygen -t rsa -f ~/.ssh/your-key-name -b 4096 -v -C root

Carregar chave pública para o servidor

$ ssh-copy-id -i ~/.ssh/your-key-name.pub [email protected]

Adicionar chave ssh ao agente

ssh-add ~/.ssh/your-key-name

Isso deve funcionar sem hacks adicionais e o gnome-keyring pode permanecer instalado.

(-C [nome de usuário] é opcional, mas exigido por provedores como o Google Cloud)

Mike
fonte
2
Sim, mas isso remove toda a funcionalidade ssh-agente que é super útil
Martin Konecny
observe-nos em qual PC usar o sudo apt-get, nosso próprio computador ou servidor remoto. obrigado.
Shicheng Guo
Chaveiro no seu próprio PC local, porque o Chaveiro faz parte do GNOME, ele geralmente não é instalado no servidor.
Mike
1
@MartinKonecny ​​bem, apenas remove o agente ssh fornecido pelo gnome, não remove o ssh-agent simples e simples do console (se você tiver o instalado). O problema é que a variedade de gnomos atrapalha o normal ssh-agent. Você ainda pode iniciar o ssh-agent e inserir senhas de chave privada no console / shell.
blubberdiblub
Isso funciona se você tiver definido o login automático para o seu DE sem digitar sua senha, porque, na verdade, seu chaveiro não será desbloqueado.
xjcl 15/04
14

Após a atualização para o Ubuntu 18.04, recebi o mesmo erro sign_and_send_pubkey: signing failed: agent refused operation. Acontece que foi causado pelas permissões da chave ssh estarem muito abertas. O comando a seguir corrigiu o problema para mim chmod 600 .ssh/id_rsa

matias
fonte
8

No meu sistema (também Ubuntu 16.04, tentando conectar-se ao github), eu tinha um arquivo id_ed25519 na minha pasta .ssh que causava ssh-addfalha:

$ ssh-add
Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)
Could not add identity "~/.ssh/id_ed25519": communication with agent failed

Depois de remover os arquivos ~/.ssh/id_ed25519*(não precisava mais deles, era de um teste anterior) tudo correu bem novamente.

Daniel Alder
fonte
2
E se você precisar deles?
Gringo Suave
@GringoSuave Boa pergunta. Você tentou? Talvez o formato tenha mudado ou não seja mais suportado pelo ssh - ou seja um bug. Pessoalmente, eu estava feliz que eu não tive que testá-lo ...
Daniel Alder
Ainda não trabalhando para mim, não tenho solução Could not add identity "~/.ssh/id_ed25519": communication with agent failed:, agente em execução e configurado, tanto quanto posso dizer.
Gringo Suave 21/10
2
A @GringoSuave a solução aqui é também livrar-se do agente de autenticação gnome que coloca um soquete de agente em seu shell no lugar do ssh-agentsoquete simples . O ssh-agent simples é capaz de lidar com chaves ED25519, enquanto o agente de autenticação gnome não é (além de outros problemas que causa). Veja a resposta de sam askubuntu.com/a/835114/167846 ou Mike askubuntu.com/a/762968/167846
blubberdiblub
7

Aconteceu comigo porque minha chave privada tinha uma senha. Teve que correr ssh-adde, em seguida, pediu a senha e acrescentou corretamente. No entanto, agora não solicita minha senha quando ssh'ing a uma máquina.

qwertzguy
fonte
6

Eu tenho uma nova instalação do Ubuntu16.04 e tive problemas semelhantes. Quando tentei clonar meu repositório no Github depois de copiar minha chave pública para o github (conforme as instruções no github.com ) e depois de executar a seguinte verificação ( recomendada no github.com ):

ssh -T [email protected]

Fui recebido pelo seguinte:

sign_and_send_pubkey: signing failed: agent refused operation
Permission denied (publickey).

Para corrigi-lo rapidamente, sem remover nada ou alterar minha configuração de inicialização, digitei o seguinte no terminal:

killall gnome-keyring-daemon

Então o clone funcionou. Em seguida, iniciei o daemon parado novamente digitando:

gnome-keyring-daemon

Mais tarde, para mudar as coisas de uma maneira mais permanente, segui os conselhos aqui

neiltheory
fonte
Isso funcionou para mim, deve ser mais votado
Sheshank S.
4

Depois de atualizar o Fedora 26 para 28, enfrentei o mesmo problema. E nenhum arquivo de log

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

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

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

chmod 700 ~/.ssh
chmod 600 ~/.ssh/*
Anto
fonte
2

Adicionando comentário, pois tive o mesmo problema com as teclas ed25519. A questão é realmente chaveiro gnomo. Para corrigir isso, fiz o seguinte:

  • Desabilitado ssh-key-agent (gnome-keyring) em "aplicativos de inicialização"
  • Matou o agente ssh-agent e gnome: (killall ssh-agent; killall gnome-keyring-daemon)
  • Reiniciou o daemon: (eval ssh-agent -s)
  • Adicione sua chave: $ ssh-add id_ed25519 Digite a senha para id_ed25519: Identidade adicionada: id_ed25519
  • Lucro!!
Matt
fonte
2

É final de 2018 e esse bug, ou variações dele, ainda atormenta o Xubuntu 16.04 e mais do que provavelmente outros sabores do Xenial. Eu não ficaria surpreso se ele existir em 18.04 também! Existe de alguma forma desde 2009, e Karmic Koala. Afetou Redhat, Debian e Ubuntu. Não aceite minha palavra, veja os rastreadores públicos:

https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/470456

E nesse bug, você também encontra listagens para os outros 3:

Referências:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322

https://bugzilla.redhat.com/show_bug.cgi?id=508286

https://bugzilla.gnome.org/show_bug.cgi?id=576700

No meu caso, o sintoma mais óbvio foi a incapacidade de usar teclas ssh com senhas. Pode afetar outros sem, pois o mau funcionamento impede que as teclas ssh sejam carregadas! E eu não tive problemas com permissões, era tudo chaveiro de gnomo. Minhas chaves (sim, ele recusou várias, para servidores SSH diferentes!) Eram todas as permissões de 600 (rw para proprietário, nada para grupo ou outro), como indicado em muitas respostas sobre isso. Então, nada que eu pudesse mudar lá.

No Xubuntu, há uma maneira de desativar itens de inicialização. Geralmente também é possível no Unity / Gnome / KDE, mas eu não os tenho instalados, por isso não posso dar etapas específicas. Não tenho certeza de outros desktops. Em vez de desativar o agente SSH, o agente GPG e outros itens do Gnome que causam isso e outros erros relacionados, desativei todos os itens de inicialização do Gnome. Pode ser um exagero ou não uma opção para alguns, mas o SSH está de volta a funcionar perfeitamente na próxima reinicialização!

  1. Abra o Menu principal do Whisker -> Configurações -> Sessão e inicialização.
  2. Clique na guia Avançado, o último à direita.
  3. Desmarque (desative) Inicie os Serviços Gnome na inicialização.
  4. Feche e reinicie. O logout também pode ser feito, mas a reinicialização deve com certeza.

Captura de tela da GUI descrita acima:

Imagem

Portanto, desde que dei minha correção acima, espero que alguém a conserte.

Provavelmente, o Ubuntu falhou em esmagá-lo para sempre, já que existem muitos tickets para vários lançamentos que afirmam que ele foi corrigido e mais que dizem "regressão", está de volta.

O Debian provavelmente quer dar um pontapé (lavar as mãos dele) porque não são eles, o upstream é o Gnome.

O Redhat provavelmente tem uma correção disponível apenas para clientes pagantes. Porque, historicamente, Redhat é o maior empregador de desenvolvedores pagos do Gnome, o que é generoso à primeira vista. Até você perceber que isso significa que eles têm incentivo financeiro para nunca colocar correções como essa nas versões gratuitas, para continuar vendendo assinaturas Redhat.

Provavelmente o Gnome é quem pode corrigi-lo com mais facilidade, e os outros podem testar e empacotar, sem escrever uma linha de código. Mas os ingressos que li dizem que o pacote definha há anos sem um mantenedor oficial! E as duas pessoas que voluntariamente o fazem agora (obrigado) estão quase tão ocupadas criando um substituto. Por que não consertar um pneu furado, mesmo que demore um ano (faz uma década!) Em vez de reinventar a roda primeiro ?!

Lubo Diakov
fonte
1

ssh-add

funciona para mim. Mas tenha certeza

ssh-agent

está correndo.

kst
fonte
1

No meu caso, o problema foi causado pelo GNOME Keyring. Para desativar os recursos SSH do gnome-keyring sem removê- lo (o que quebra muitas coisas), siga estas instruções :

cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart
echo Hidden=true >> ~/.config/autostart/gnome-keyring-ssh.desktop

e reinicie a sessão. Agora você pode executar o ssh-agent sem que o gnome-keyring interfira.

Norrius
fonte
0

Tentei algumas coisas, entre outras, o ssh-add, redefinindo o SSH (excluindo .ssh / no servidor e assim por diante, mas sem sorte. Então, aconteceu que tive que dormir por uma noite. Ajudou! Por que "Eu acho que o ssh-agent em execução no servidor tinha algo em seu cache que foi atualizado mais tarde naquela noite com os valores agora adequados. De qualquer forma, agora funciona como um encanto. Para finalizar, ele fez isso (Ubuntu 16.04 on localhost, 14.04 no servidor).

# on local host:
$ ssh-keygen
# (yes, overwrite the default file, and let the passphrase be empty)
$ ssh-copy-id ***.***.*.**
# (insert proper server IP address)
# now test
$ ssh ***.***.*.**
# this should have erected in .ssh/ on the server:
# -rw------- 1 *** *** 2000 aug.  11 09:55 authorized_keys
# no other magic going on! :)
até
fonte
0

Acabei soltando meu arquivo hosts conhecido e funcionou. Tinha que colocar uma senha novamente, mas finalmente aceitou a senha correta. Foi após uma nova instalação.

possumkeys
fonte
0

Se adicionar SSH_AUTH_SOCK = 0 antes do comando ssh ajudar, será uma falha no chaveiro do gnome. Exceto as soluções e os problemas fornecidos, o problema pode estar relacionado à senha. Se você tiver uma senha para a chave, o chaveiro do gnome perguntará quando você fizer o login pela primeira vez e se você digitar vazio por falha ou fechar inesperadamente a janela, o gnome assumirá como senha vazia e a lembrará para sempre. Nada ajuda a ser solicitado novamente para a senha. Para resolver o aplicativo ssh keyring aberto, acesse a seção Login na categoria Senhas. Localize o registro correspondente à chave problemática e digite Propriedades e digite a senha correta.

Fazliddin
fonte
0

Há outra causa disso que ainda não está em resposta: o formato PEM para o arquivo-chave deixou de ser o padrão ssh-keygenantes de o Ubuntu mudar para um gnome-keyring-daemonque suporte o novo formato RFC4716.

Se você gerar uma nova chave ou adicionar / remover uma senha de sua chave, ela poderá quebrar. A chave está sendo usada ssh-keygen -m PEMantes de qualquer outra operação que você precise executar. Por exemplo, você pode converter novamente para o formato antigo usando ssh-keygen -m PEM -pe inserindo a senha antiga como a nova senha (que estaria vazia para nenhuma senha).

Sam Brightman
fonte