Ainsi, après des heures de recherche insensée sur Google et d'aide, le problème a été découvert. Je générais mes clés ssh avec ssh-keygen et j'ai ajouté un argument supplémentaire "-o" qui a généré les clés dans un nouveau format pour openSSH. Le problème était que mon trousseau de clés gnome ne prenait pas en charge ces clés car les clés avaient le schéma de signature Ed255519. Gnome-keyring ne le supporte plus depuis la version 3.20. Je suis revenu à RSA et plus de problèmes !
Dans mon cas, le problème était que le trousseau de clés GNOME contenait une phrase secrète non valide pour la clé ssh à utiliser. Après avoir passé un temps indécent à résoudre ce problème, j'ai exécuté seahorse et trouvé l'entrée contenant une chaîne vide.
Je ne peux que deviner que cela a été causé par une mauvaise saisie de la phrase secrète lors de la première utilisation quelque temps auparavant, puis probablement par l'annulation du demandeur afin de revenir à la ligne de commande.
-
La mise à jour de l'entrée avec la 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 ressaisie de la phrase secrète à cette première invite (et la vérification de la case à cocher appropriée) résolvent également ce problème.
Maintenant, l'agent obtient la phrase secrète correcte à partir du trousseau de clés déverrouillé à la connexion nommé "login" et ne demande plus de phrase secrète ni "refuse l'opération". Bien sûr YMMV.