Comment résoudre «sign_and_send_pubkey: échec de la signature: opération refusée par l'agent»?

Configuration d'un nouveau droplet Digital Ocean avec des clés SSH. Quand je cours, voici ssh-copy-idce que j'obtiens:

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.

Cependant, lorsque j'essaye ensuite de ssh, cela se produit:

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

En entrant le mot de passe, je suis connecté très bien, mais cela va bien sûr à l'encontre de l'objectif de création de la clé SSH en premier lieu. J'ai décidé de jeter un œil au côté serveur ssh-agent et voici ce que j'obtiens:

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 / allowed_keys contient également une entrée de clé ssh-rsa, mais find -name "keynamehere"ne renvoie rien.

Exécutez ssh-addsur la machine cliente, cela ajoutera la clé SSH à l'agent.

Confirmez avec ssh-add -l(à nouveau sur le client) qu'il a bien été ajouté.

Après la mise à niveau de Fedora 26 vers 28, j'ai rencontré le même problème. Et les journaux suivants manquaient

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

PROBLÈME:

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

le message d'erreur ne pointe pas le problème réel. Problème résolu par

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

J'avais le même problème sous Linux Ubuntu 18 . Après la mise à jour d' Ubuntu 17.10 , chaque commande git afficherait ce message.

Le moyen de le résoudre est de vous assurer que vous disposez de la bonne autorisation sur le id_rsaet id_rsa.pub.

Vérifiez le numéro de chmod actuel en utilisant stat --format '%a' <file>. Il devrait être 600 pour id_rsa et 644 pour id_rsa.pub.

Pour modifier l'autorisation sur les fichiers, utilisez

chmod 600 id_rsa
chmod 644 id_rsa.pub

Cela a résolu mon problème avec la mise à jour.

Exécutez la commande ci-dessous pour résoudre ce problème.

Cela a fonctionné pour moi.

chmod 600 ~/.ssh/id_rsa

J'ai eu l'erreur en utilisant gpg-agent comme mon agent ssh et en utilisant une sous-clé gpg comme ma clé ssh https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .

Je soupçonne que le problème a été causé par un tty d'entrée de broche non valide pour gpg causé par ma commande sleep + lock utilisée dans ma configuration sway

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

ou juste le sommeil / suspension

Réinitialisez le tty d'entrée de broche pour résoudre le problème

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

et le correctif pour ma commande 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'"

À cette erreur:

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

Vérifiez ou ajoutez à nouveau la clé publique dans Compte Github> profil> ssh.

J'ai résolu comme ceci:

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

Je vous remercie.

Il peut y avoir différentes raisons pour obtenir l'erreur SSH:

sign_and_send_pubkey: échec de la signature: opération refusée par l'agent

Certains d'entre eux pourraient être liés aux problèmes mis en évidence par les autres réponses (voir les réponses de ce fil de discussion), certains d'entre eux pourraient être cachés et nécessiteraient donc une enquête plus approfondie.

Dans mon cas, j'ai le message d'erreur suivant:

sign_and_send_pubkey: échec de la signature: opération refusée par l'agent

user@website.domain.com: Autorisation refusée (publickey, gssapi-keyex, gssapi-with-mic)

La seule façon de trouver le vrai problème était d'appeler l' option -v verbose, ce qui entraînait l'impression de nombreuses informations de débogage:

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

Veuillez noter que la ligne disant key_load_public: No such file or directoryfait référence à la ligne suivante et non à la ligne précédente.

Donc, ce que SSH dit vraiment, c'est qu'il n'a pas pu trouver le fichier de clé publique nommé id_rsa.website.domain.com-certet cela semblait être le problème dans mon cas puisque mon fichier de clé publique ne contenait pas le -certsuffixe.

Pour faire court: le correctif dans mon cas était simplement de s'assurer que le fichier de clé publique était nommé comme prévu. Je ne pourrais jamais soupçonner cela sans déboguer la connexion.

La ligne du bas est UTILISER LE MODE VERBOSE SSH (option -v) pour déterminer ce qui ne va pas, il peut y avoir plusieurs raisons, aucune qui ne peut être trouvée sur ce / un autre thread.

Cela devrait être plutôt une question SuperUser.

À droite, j'ai exactement la même erreur dans MacOSX SourceTree, cependant, dans un terminal iTerm2, les choses fonctionnent parfaitement.

Cependant, le problème semble être que j'ai deux ssh-agent s en cours d'exécution; (

Le premier étant /usr/bin/ssh-agent(aka MacOSX), puis le HomeBrew installé en /usr/local/bin/ssh-agentcours d'exécution.

Lancer un terminal à partir de SourceTree, m'a permis de voir les différences SSH_AUTH_SOCK, en utilisant, lsofj'ai trouvé les deux différents ssh-agents, puis j'ai pu charger les clés (en utilisant ssh-add) dans le système par défaut ssh-agent(c'est-à-dire /usr/bin/ssh-agent), SourceTree fonctionnait à nouveau.

Oui. Exécutez ssh-add sur la machine cliente. Puis répétez la commande ssh-copy-id userserver@012.345.67.89

Pour moi, le problème était un mauvais copier / coller de la clé publique dans Gitlab. La copie a généré un retour supplémentaire. Assurez-vous que ce que vous collez est une clé d'une ligne.

J'ai aussi une sign_and_send_pubkey: signing failed: agent refused operationerreur. Mais dans mon cas, le problème était un fauxpinentry chemin.

Dans mon ${HOME}/.gnupg/gpg-agent.confla pinentry-programpropriété a été pointant vers un ancien chemin de pinentry. Corriger le chemin et redémarrer legpg-agent corrigé pour moi.

Je l'ai découvert en suivant les logs avec journalctl -f. Là où des lignes de journal comme les suivantes contiennent le mauvais chemin:

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

J'ai besoin de partager, car j'ai passé trop de temps à chercher une solution

Voici la solution: https://unix.stackexchange.com/a/351742/215375

J'utilisais cette commande:

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

gnome-keyring ne prend pas en charge la clé générée.

La suppression de l' -oargument a résolu le problème.

Dans mon cas, le problème était que le trousseau de clés GNOME contenait une phrase de passe invalide pour la clé ssh à utiliser. Après avoir passé un temps indécent à résoudre ce problème, j'ai couru seahorseet j'ai trouvé l'entrée contenant une chaîne vide. Je ne peux que supposer que cela a été causé par une mauvaise saisie de la phrase de passe lors de la première utilisation quelque temps plus tôt, puis par l'annulation probablement du demandeur afin de revenir à la ligne de commande. La mise à jour de l'entrée avec une phrase de passe correcte a immédiatement résolu le problème. La suppression de cette entrée (du trousseau de clés "login") et la saisie à nouveau de la phrase de passe à cette première invite (et en cochant la case appropriée) résout également ce problème. L'agent obtient maintenant la phrase de passe correcte du trousseau de clés déverrouillé à la connexion nommé "login" et ne demande plus de phrase de passe ni "refuse l'opération". Bien sûr, YMMV.

Ce qui a fonctionné ici: sur le client

1) ssh-add

2) ssh-copy-id utilisateur @ serveur

Les clés ont été créées il y a quelque temps avec "ssh-keygen -t rsa". J'ai sw le message d'erreur parce que j'ai copié ma clé publique ssh du client au serveur (avec ssh-id-copy) sans exécuter ssh-add en premier, puisque j'ai supposé à tort que je les avais ajoutés quelque temps plus tôt.

note rapide pour ceux qui ont récemment mis à jour vers la version ssh "moderne" [OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS 10 sept. 2019] - fourni avec fedora 31, semble ne plus accepter les anciennes clés DSA SHA256 (les miennes sont datées de 2006!) - a créé une nouvelle clé rsa, publique ajoutée à autorisée, privée sur le client, et tout fonctionne parfaitement.

merci pour les suggestions précédentes, en particulier le ssh -v a été très utile