Je viens de mettre à niveau mon système Ubuntu de 15.10 à 16.04 en effaçant complètement la partition Ubuntu 15 de mon système.

Après l’installation d’Ubuntu 16.04, j’ai recréé mes clés ssh car j’ai oublié de les sauvegarder, mais chaque fois que j’essaie d’utiliser ssh, j’obtiens un sign_and_send_pubkey: signing failed: agent refused operationpeu gênant car cela me permet de passer par mon serveur ssh, mais git refuse de pousser du code avec ssh.

J'ai déjà poussé les clés sur le serveur en utilisant ssh-copy-id.

Le serveur auquel je me connecte est un serveur Ubuntu 16.04 mis à niveau via la do-release-upgradecommande. Toute aide sera fortement appréciée.

On dirait que an ssh-agentest déjà en cours d'exécution, mais il ne peut trouver aucune clé attachée. Pour résoudre ce problème, ajoutez les identités de clé privée à l'agent d'authentification comme suit:

ssh-add

Ensuite, vous pouvez sshdans votre serveur.

De plus, vous pouvez voir la liste des empreintes de toutes les identités actuellement ajoutées par:

ssh-add -l

Solution simple

J'ai eu le même problème à Ubuntu 18.04. C'est tout sur les autorisations de clé privée côté client .

$ ssh root@192.168.1.1
sign_and_send_pubkey: signing failed: agent refused operation

Les autorisations de fichier étaient trop ouvertes (0644).

La commande suivante l'a résolu:

chmod 600 ~/.ssh/id_rsa

J'ai eu le même problème (mêmes symptômes)

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

... mais la solution était différente.

Le problème venait de l’utilisation de GNOME-KEYRING. Le post faisant référence à la solution peut être lu ici .

En bref:

1. Détectez le problème en ajoutant SSH_AUTH_SOCK = 0 devant la commande ssh. sam @ xxxxx: ~ / .ssh $ SSH_AUTH_SOCK = 0 ssh centos@123.123.123.123
2. En cas de réussite de la connexion. Ouvrez l'application StartUp Application (à l'aide de la fonction de recherche du bureau, par exemple) et désactivez l'utilisation de gnome-keyring.
3. Redémarrer

La page fournit d'autres détails en cas de problème similaire avec une solution différente.

sign_and_send_pubkey: signing failed: agent refused operationLorsque je me connectais à plusieurs serveurs, lisez la réponse de VonC sur le dépassement de pile pour plus d'informations sur les bogues liés. La solution pour moi était de supprimer gnome-keyring, de supprimer les identités de ssh-agent et de redémarrer.

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

Puis toutes mes clés ont commencé à fonctionner parfaitement.

MISE À JOUR:

Solution temporaire sans désinstaller le trousseau

Si vous voulez conserver le gnome-keyring et que vous avez l' agent refused operationerreur, utilisez:

eval `ssh-agent -s`
ssh-add

Ou utiliser SSH_AUTH_SOCK=0 ssh your-server

La solution permanente sans désinstaller le trousseau

Si vous le pouvez, gnome-keyring est compatible avec la clé RSA de 4096 bits. Il vous suffit donc de générer une nouvelle clé avec:

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

Télécharger la clé publique sur le serveur

$ ssh-copy-id -i ~/.ssh/your-key-name.pub root@12.34.56.78

Ajouter la clé ssh à l'agent

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

Cela devrait fonctionner sans aucun piratage supplémentaire et gnome-keyring peut rester installé.

(Le -C [nom d'utilisateur] est facultatif, mais requis par des fournisseurs tels que Google Cloud)

Après la mise à niveau vers Ubuntu 18.04, j'ai eu la même erreur sign_and_send_pubkey: signing failed: agent refused operation. Il s'avère que cela a été causé par les autorisations de la clé ssh trop ouverte. La commande suivante a résolu le problème pour moi chmod 600 .ssh/id_rsa

Sur mon système (également Ubuntu 16.04, essayant de se connecter à github), j'avais un fichier id_ed25519 dans mon dossier .ssh qui faisait ssh-addéchouer:

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

Après avoir supprimé les fichiers ~/.ssh/id_ed25519*(je n'en avais plus besoin, c'était d'un test précédent), tout s'est bien passé.

Cela m'est arrivé parce que ma clé privée avait un mot de passe complexe. Devait courir ssh-addet ensuite il a demandé la phrase secrète et ajouté correctement. Cependant, maintenant, il ne me demande plus mon mot de passe lorsque je passe à une machine.

J'ai une nouvelle installation d'Ubuntu16.04 et j'ai rencontré des problèmes similaires. Lorsque j'ai essayé de cloner mon référentiel à partir de Github après avoir copié ma clé publique sur github (conformément aux instructions de github.com ) et après avoir effectué le contrôle suivant ( recommandé sur github.com ):

ssh -T git@github.com

J'ai été accueilli par ce qui suit:

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

Pour résoudre ce problème rapidement, sans rien enlever ni changer de configuration de démarrage, je viens de taper ce qui suit dans le terminal:

killall gnome-keyring-daemon

Ensuite, le clone a fonctionné. J'ai ensuite redémarré le démon arrêté en tapant:

gnome-keyring-daemon

Plus tard, pour changer les choses de manière plus permanente, j’ai suivi le conseil ici

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

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

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/*

Ajout de commentaire car j'avais le même problème avec les clés ed25519. Le problème est bien gnome-keyring. Pour résoudre ce problème, j'ai fait ce qui suit:

• Ssh-key-agent (gnome-keyring) décoché dans les "applications de démarrage"
• Tué des agents ssh-agent et gnome: (killall ssh-agent; killall gnome-keyring-daemon)
• Relancez le démon: (eval ssh-agent -s)
• Ajoutez votre clé: $ ssh-add id_ed25519 Entrez la phrase secrète pour id_ed25519: Identité ajoutée: id_ed25519
• Profit!!

Il est fin 2018, et ce bug, ou des variantes de celui-ci, continuent de nuire à Xubuntu 16.04, et probablement à d'autres parfums de Xenial. Je ne serais pas surpris s'il existe aussi en 18.04! Il existe depuis 2009 sous une forme ou une autre, Karmic Koala. A affecté Redhat, Debian et Ubuntu. Ne me croyez pas sur parole, voyez les boguepiles publics:

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

Et à ce bogue, vous trouvez également des listes pour les 3 autres:

Références:

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

Dans mon cas, le symptôme le plus évident était l’incapacité à utiliser les clés SSH avec des phrases secrètes. Cela peut affecter les autres sans, car le dysfonctionnement empêche le chargement des clés ssh! Et je n’avais aucun problème d’autorisations, c’était tout gnome-keyring. Mes clés (oui, il en a refusé plusieurs, pour différents serveurs SSH!), Les autorisations étaient au nombre de 600 (RW pour le propriétaire, rien pour le groupe ou autre), comme indiqué dans de nombreuses réponses à ce sujet. Donc rien que je puisse changer là.

Dans Xubuntu, il existe un moyen de désactiver les éléments de démarrage. Généralement aussi possible dans Unity / Gnome / KDE, mais je n'ai pas ceux installés, donc je ne peux pas donner des étapes spécifiques. Pas sûr des autres ordinateurs de bureau. Plutôt que de désactiver l'agent SSH, l'agent GPG et d'autres éléments de Gnome à l'origine de cette situation, ainsi que d'autres bogues connexes, j'ai désactivé tous les éléments de démarrage de Gnome. Peut-être exagéré ou pas une option pour certains, mais SSH est de retour à travailler sans faille lors du prochain redémarrage!

1. Ouvrez le menu principal Whisker -> Paramètres -> Session et démarrage.
2. Cliquez sur l'onglet Avancé, le dernier à droite.
3. Décochez (désactiver) Lancez les services Gnome au démarrage.
4. Fermez et redémarrez. Se déconnecter peut le faire aussi, mais redémarrer devrait à coup sûr.

Capture d'écran de l'interface graphique décrite ci-dessus:

Donc, puisque j'ai donné mon correctif ci-dessus, j'espère que quelqu'un va le réparer.

Ubuntu a visiblement échoué à l'écraser pour de bon, car il y a beaucoup de tickets pour plusieurs versions qui prétendent qu'il est corrigé, et d'autres qui disent "régression", c'est de retour.

Debian veut probablement piquer (s'en laver les mains) car ce n'est pas eux, Gnome est en amont.

Redhat a probablement un correctif uniquement disponible pour les clients payants. Parce que, historiquement, Redhat est le plus gros employeur de développeurs de gnomes rémunérés, ce qui est généreux à première vue. Jusqu'à ce que vous réalisiez que cela signifie qu'ils ont un intérêt financier à ne jamais mettre de tels correctifs dans les versions gratuites, à continuer à vendre des abonnements Redhat.

Gnome est probablement celui qui peut le réparer le plus facilement en amont, puis les autres peuvent tester et empaqueter, sans écrire eux-mêmes une ligne de code. Mais les billets que j'ai lus disent que le paquet languit depuis des années sans entretien officiel! Et les deux personnes qui le font volontairement maintenant (merci) sont presque aussi occupées à concevoir un remplaçant. Pourquoi ne pas réparer un pneu crevé même si cela prend un an (ça fait une décennie!) Au lieu de réinventer la roue d’abord?!

ssh-add

travaille pour moi. Mais soyez sûr

ssh-agent

est en cours d'exécution.

Dans mon cas, le problème était causé par GNOME Keyring. Pour désactiver les fonctionnalités SSH de gnome-keyring sans les supprimer (ce qui casse beaucoup de choses), suivez ces instructions :

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

et redémarrez la session. Vous pouvez maintenant exécuter ssh-agent sans interférer avec gnome-keyring.

J'ai essayé plusieurs choses, parmi lesquelles ssh-add, réinitialiser SSH (supprimer .ssh / sur le serveur, etc., mais pas de chance. Il est donc apparu que je devais dormir dessus pendant une nuit. Cela a aidé! Pourquoi "Je suppose que ssh-agent fonctionnant sur le serveur avait quelque chose dans son cache qui a été actualisé plus tard dans la nuit avec les valeurs appropriées. De toute façon, cela fonctionne maintenant comme un charme. Pour conclure, il l'a fait (Ubuntu 16.04 sur localhost, 14.04 sur le serveur).

# 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! :)

J'ai fini par déposer mon fichier d'hôtes connus et cela a fonctionné. J'ai dû mettre un mot de passe à nouveau, mais il a finalement accepté le bon mot de passe. C'était après une nouvelle installation.

Si l'ajout de SSH_AUTH_SOCK = 0 avant que la commande ssh ne vous aide, c'est alors gnome keyring fault. Sauf si les solutions et les problèmes sont fournis, le problème peut être lié à la phrase secrète. Si vous avez une phrase secrète pour la clé, gnome keyring vous le demandera lors de votre première connexion et si vous entrez vide par erreur ou fermez la fenêtre de manière inattendue, gnome l'assume comme une phrase secrète vide et s'en souvient indéfiniment. Rien n'aide à être invité à nouveau pour le mot de passe. Pour résoudre l'application ssh keyring ouverte et aller à la section de connexion sous la catégorie mots de passe. Recherchez l'enregistrement correspondant à la clé problématique, entrez dans Propriétés et entrez le mot de passe correct.

Il y a une autre cause à cela qui ne figure pas encore dans la réponse: le format PEM du fichier de clé a cessé d'être la valeur par défaut ssh-keygenavant qu'Ubuntu ne soit passé à un gnome-keyring-daemonformat prenant en charge le nouveau format RFC4716.

Si vous générez une nouvelle clé ou ajoutez / supprimez une phrase secrète de votre clé, celle-ci risque de se rompre. La clé utilise ssh-keygen -m PEMavant toute autre opération à exécuter. Par exemple, vous pouvez reconvertir l'ancien format en utilisant ssh-keygen -m PEM -pet en entrant l'ancienne phrase secrète en tant que nouvelle phrase secrète (qui serait vide sans phrase secrète).