Ubuntu 16.04 ssh: sign_and_send_pubkey: la signature a échoué: l'agent a refusé l'opération

115

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

Après avoir installé Ubuntu 16.04, j'ai recréé mes clés ssh en oubliant de les sauvegarder, mais chaque fois que j'essaie d'utiliser ssh, j'obtiens sign_and_send_pubkey: signing failed: agent refused operation . push code en utilisant 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 commande do-release-upgrade . Toute aide sera grandement appréciée.

    
posée Gamerb 25.04.2016 - 18:31
la source

12 réponses

219

On dirait qu'un ssh-agent est déjà en cours d'exécution mais qu'il ne trouve 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 ssh sur votre serveur.

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

ssh-add -l
    
réponse donnée Ron 25.04.2016 - 18:52
la source
24

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

[email protected]:~/.ssh$ ssh [email protected]
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 [email protected]
  2. Au cas où il parviendrait à se connecter. Ouvrez l'application StartUp Application (en utilisant 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.

    
réponse donnée sam 10.10.2016 - 08:59
la source
13

J'obtenais le sign_and_send_pubkey: signing failed: agent refused operation lors de la connexion à plusieurs serveurs, lisez la réponse de VonC sur Débordement de pile pour plus d'informations sur les bogues associé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

Ensuite, toutes mes clés ont fonctionné parfaitement.

MISE À JOUR:

Solution temporaire sans désinstallation du trousseau de clés

Si vous souhaitez conserver le gnome-keyring et que vous avez l'erreur agent refused operation , utilisez:

eval 'ssh-agent -s'
ssh-add

ou utilisez SSH_AUTH_SOCK=0 ssh your-server

La solution permanente sans désinstallation du trousseau de clés

Si vous le pouvez, gnome-keyring est compatible avec la clé RSA 4096 bits, il 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 [email protected]

Ajouter la clé ssh à l'agent

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

Cela devrait fonctionner sans hacks supplémentaires et gnome-keyring peut rester installé.

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

    
réponse donnée Mike 26.04.2016 - 09:38
la source
8

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

$ 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* (ils n’en avaient plus besoin, c’était à partir d’un test précédent), tout s’est bien passé.

    
réponse donnée Daniel Alder 11.06.2016 - 17:56
la source
6

Cela m'est arrivé parce que ma clé privée avait une phrase secrète. Doit exécuter ssh-add , puis il a demandé la phrase secrète et ajouté correctement. Cependant, il ne demande plus mon mot de passe lors de la connexion à une machine.

    
réponse donnée qwertzguy 16.02.2017 - 02:02
la source
6

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 est dû au fait que les autorisations de la clé ssh sont trop ouvertes. La commande suivante a résolu le problème pour moi chmod 600 .ssh/id_rsa

    
réponse donnée matthias 04.05.2018 - 17:44
la source
5

Solution simple

J'ai eu le même problème chez Ubuntu 18.04. Tout cela concerne les autorisations de clé privée côté client.

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

Les permissions du fichier étaient trop ouvertes (0644).

La commande suivante a résolu le problème:

chmod 600 .ssh/id_rsa
    
réponse donnée Antonio Feitosa 31.05.2018 - 16:56
la source
2

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

  • Un agent ssh-key-agent (gnome-keyring) non contrôlé dans les "applications de démarrage"
  • Tue l'agent ssh et l'agent gnome: (killall ssh-agent; killall gnome-keyring-daemon)
  • A redémarré 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 !!
réponse donnée Matt 16.12.2016 - 16:03
la source
2

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

[email protected]  ~  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/*
    
réponse donnée Anto P Joseph 09.06.2018 - 12:15
la source
0

J'ai essayé plusieurs choses, entre autres ssh-add, en réinitialisant SSH (en supprimant .ssh / sur le serveur, etc.). Je pense que le ssh-agent fonctionnant sur le serveur a quelque chose dans son cache qui a été mis à jour plus tard dans la nuit avec les valeurs maintenant correctes. 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! :)
    
réponse donnée untill 11.08.2016 - 10:12
la source
0

J'ai fini par déposer mon fichier d'hôtes connu 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.

    
réponse donnée possumkeys 01.11.2016 - 08:46
la source
0

Il est à la fin de 2018, et ce bug, ou des variantes de celui-ci, sévit encore dans Xubuntu 16.04, et plus que probablement d'autres saveurs de Xenial. Je ne serais pas surpris si cela existe aussi au 18.04! Il existe depuis 2009 et Karmic Koala. A affecté Redhat, Debian et Ubuntu. Ne me croyez pas sur parole, voir les bugtrackers publics:

lien

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

Références:

lien

lien

lien

Dans mon cas, le symptôme le plus évident était l’incapacité à utiliser des clés ssh avec des phrases de passe. Cela peut également affecter ceux sans, car le dysfonctionnement empêche les clés ssh de se charger du tout! Et je n'avais pas de problèmes d'autorisations, c'était tout gnome-keyring. Mes clés (oui, il en a refusé plusieurs, pour différents serveurs SSH!), Les autorisations étaient toutes 600 (rw pour le propriétaire, rien pour le groupe ou autre) comme indiqué dans de nombreuses réponses à ce sujet. Donc, je ne pouvais rien y changer.

Dans Xubuntu, il existe un moyen de désactiver les éléments de démarrage. Habituellement aussi possible dans Unity / Gnome / KDE, mais je ne les ai pas installés, donc je ne peux pas donner d’étapes spécifiques. Pas sûr des autres ordinateurs de bureau. Plutôt que de désactiver l'agent SSH, l'agent GPG et les autres éléments de Gnome qui causent cela, ainsi que d'autres bogues associés, j'ai désactivé tous les éléments de démarrage de Gnome. Peut être excessif ou pas une option pour certains, mais SSH est de retour à travailler parfaitement au prochain redémarrage!

  1. Ouvrez le menu principal de Whisker - & gt; Paramètres - & gt; Session et démarrage.
  2. Cliquez sur l'onglet Avancé, dernier sur la droite.
  3. Décochez (désactivez) Lancez les services Gnome au démarrage.
  4. Fermez et redémarrez. La déconnexion peut aussi le faire, mais le redémarrage devrait à coup sûr.

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

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

Ubuntu n’a pas réussi à l’écraser pour de bon, car il ya beaucoup de tickets pour plusieurs versions qui prétendent qu’il est corrigé, et d’autres qui disent "régression", il est de retour.

Debian veut probablement jeter les mains dessus car ce n’est pas eux, en amont, Gnome.

Redhat a probablement un correctif uniquement disponible pour les clients payants. Car, historiquement, Redhat est le plus gros employeur de développeurs payants de Gnome, ce qui est généreux à première vue. Jusqu'à ce que vous réalisiez que cela signifie qu'ils ont une incitation financière à ne jamais mettre de telles solutions dans les versions gratuites, pour continuer à vendre des abonnements Redhat.

Gnome est probablement celui qui peut le réparer plus facilement en amont, puis les autres peuvent tester et compiler sans écrire une ligne de code eux-mêmes. Mais les billets que j'ai lus disent que le paquet a traîné pendant des années sans un responsable 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 10 ans!) Au lieu de réinventer la roue en premier?!

    
réponse donnée Lubo Diakov 23.07.2018 - 16:19
la source

Lire d'autres questions sur les étiquettes