Ubuntu 16.04 ssh: sign_and_send_pubkey: échec de la signature: opération refusée par l'agent
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 sign_and_send_pubkey: signing failed: agent refused operation, ce qui est légèrement 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 commande do-release-upgrade. Toute aide est la bienvenue.
On dirait qu'un ssh-agent est 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 ssh sur votre serveur.
de plus, vous pouvez voir la liste des empreintes de toutes les identités actuellement ajoutées par:
ssh-add -l
J'ai eu le même problème (mêmes symptômes)
sam@xxxxx:~/.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:
- 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]
- 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.
- Redémarrer
La page fournit d'autres détails en cas de problème similaire avec une solution différente.
Solution simple
J'ai eu le même problème à Ubuntu 18.04. C'est tout sur le côté client autorisations de clé privée.
$ ssh [email protected]
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'obtenais le sign_and_send_pubkey: signing failed: agent refused operation lors de la connexion à plusieurs serveurs, lisez réponse de VonC sur Stack Overflow pour plus d'informations sur les bogues liés, la solution pour moi consistait à supprimer gnome-keyring, à supprimer les identités de ssh-agent et à redémarrer.
Sudo apt-get autoremove gnome-keyring
ssh-add -D
Puis toutes mes clés ont commencé à fonctionner parfaitement.
UPDATE:
Solution temporaire sans désinstaller le trousseau de clés
Si vous voulez 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ésinstaller le trousseau de clés
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 [email protected]
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 rendait ssh-add défaillant:
$ 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. Dû exécuter ssh-add puis il a demandé la phrase secrète et l'a ajouté correctement. Cependant, maintenant, il ne me demande plus mon mot de passe lorsque je passe à une machine.
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 [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'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 (comme indiqué par les instructions sur github.com ) et après avoir effectué le contrôle suivant ( recommandé sur github .com ):
ssh -T [email protected]
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
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)
- Redémarrez 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!!
ssh-add
travaille pour moi. Mais soyez sûr
ssh-agent
est en cours d'exécution.
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 prenez pas ma parole pour cela, voir les bogues 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=5767
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!
- Ouvrez le menu principal Whisker -> Paramètres -> Session et démarrage.
- Cliquez sur l'onglet Avancé, le dernier à droite.
- Décocher (désactiver) Lancer les services Gnome au démarrage.
- 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 une ligne de code eux-mêmes. 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?!
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 un mot de passe composé 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 le considère comme un mot de passe complexe et le mémorise à jamais. 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.
Dans mon cas, le problème était causé par GNOME Keyring. Pour désactiver les capacités SSH de gnome-keyring sans carrément supprimer le (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 m'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! :)
Il existe une autre cause à cela qui ne figure pas encore dans la réponse: le format PEM du fichier de clé a cessé d'être le code par défaut pour ssh-keygen avant qu'Ubuntu ne soit passé à un gnome-keyring-daemon qui prend 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 PEM avant toute autre opération à exécuter. Par exemple, vous pouvez reconvertir l'ancien format en utilisant ssh-keygen -m PEM -p et en entrant l'ancienne phrase secrète en tant que nouvelle phrase secrète (qui serait vide si aucune phrase secrète n'est définie).