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 lance ssh-copy-id, voici ce que je reçois:
ssh-copy-id [email protected]
/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
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'"
and check to make sure that only the key(s) you wanted were added.
Cependant, lorsque je tente ensuite de ssh, cela se produit:
ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'s password:
Lorsque je saisis le mot de passe, je me connecte parfaitement, mais cela va naturellement à l’encontre du but de créer la clé SSH. J'ai décidé de jeter un coup d'œil au côté serveur ssh-agent et voici ce que je reçois:
[email protected]:~# eval `ssh-agent -s`
Agent pid 5715
[email protected]:~# ssh-add -l
The agent has no identities.
user/.ssh/registered_keys contient également une entrée de clé ssh-rsa, mais find -name "keynamehere" ne renvoie rien.
Exécutez ssh-add sur la machine cliente, ce qui 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 à 28, j’ai été confronté au même problème .
/var/log/secure
/var/log/messages
PROBLÈME:
antop@localmachine ~ ssh [email protected]
sign_and_send_pubkey: signing failed: agent refused operation
[email protected]'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 dansLinux Ubuntu 18. Après la mise à jour deUbuntu 17.10, chaque commande git afficherait ce message.
Pour résoudre ce problème, assurez-vous que vous disposez des droits corrects sur id_rsa et id_rsa.pub.
Vérifiez le numéro de chmod actuel en utilisant stat --format '%a' <file>. Ce devrait être 600 pour id_rsa et 644 pour id_rsa.pub.
Pour changer les permissions sur les fichiers, utilisez
chmod 600 id_rsa
chmod 644 id_rsa.pub
Cela a résolu mon problème avec la mise à jour.
J'ai eu l'erreur en utilisant gpg-agent comme ssh-agent et en utilisant une sous-clé gpg comme clé ssh https://wiki.archlinux.org/index.php/GnuPG#gpg-agent .
Je soupçonne que le problème a été provoqué par le fait d'avoir un tty d'entrée de broche invalide pour gpg, provoqué 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/suspendre
Réinitialiser le tty 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
[email protected]: 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 rajoutez la clé publique dans le compte Github> profile> ssh.
J'ai résolu comme ça:
# 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.
Cela devrait être plutôt une question de superutilisateur.
À droite, j'ai exactement la même erreur dans MacOSX SourceTree, cependant, dans un terminal iTerm2, les choses fonctionnent à merveille.
Cependant, le problème semblait être que j'ai deuxssh-agents en cours d'exécution ((
Le premier étant /usr/bin/ssh-agent (MacOSX), puis HomeBrew a installé /usr/local/bin/ssh-agent en cours d'exécution.
Démarrer un terminal depuis SourceTree, m'a permis de voir les différences dans SSH_AUTH_SOCK, en utilisant lsof, j'ai trouvé les deux ssh-agents différents, puis j'ai pu charger les clés (avec ssh-add) dans le ssh-agent par défaut du système (c'est-à-dire /usr/bin/ssh-agent), SourceTree fonctionnait à nouveau.
Il peut y avoir plusieurs raisons pour obtenir l’erreur SSH:
sign_and_send_pubkey: échec de la signature: opération refusée par l'agent
Certaines d'entre elles pourraient être liées aux problèmes mis en évidence par les autres réponses (voir les réponses dans ce fil), d'autres pourraient être masquées 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
[email protected]: autorisation refusée (publickey, gssapi-keyex, gssapi-with-mic)
Le seul moyen 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 directory fait 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-cert et que cela semblait être le problème dans mon cas puisque mon fichier de clé publique ne contenait pas le suffixe -cert.
Longue histoire courte: la solution dans mon cas était juste de m'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 UTILISEZ LE MODE SSH VERBOSE (option -v) pour comprendre ce qui ne va pas, il peut y avoir plusieurs raisons, dont aucune qui pourrait être trouvée sur ce/un autre thread.
J'ai aussi une erreur sign_and_send_pubkey: signing failed: agent refused operation. Mais dans mon cas, le problème était un mauvais chemin pinentry.
Dans mon ${HOME}/.gnupg/gpg-agent.conf, la propriété pinentry-program pointait vers un ancien chemin Pinentry. Corriger le chemin et redémarrer le gpg-agent le corrigea pour moi.
Je l'ai découvert en suivant les journaux avec journalctl -f. Il y avait des lignes de journal comme celles-ci contenant 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
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.
Oui. Exécutez ssh-add sur l'ordinateur client . Répétez ensuite la commande ssh-copy-id [email protected]