Comment désactiver l'intégration ssh de gnome-keyring ?

Il suffit de copier les .desktop fichier de /etc/xdg/autostart a ~/.config/autostart et ajouter Hidden=true à ce sujet :

(cat /etc/xdg/autostart/gnome-keyring-ssh.desktop; echo Hidden=true) > ~/.config/autostart/gnome-keyring-ssh.desktop

puis recharger gnome-Shell (presse Alt + F2 puis tapez r et appuyez sur Enter ).

C'est le seul solution conviviale qui a fonctionné pour moi (c'est-à-dire qu'il n'est pas nécessaire d'établir une liaison logicielle avec le site web). .desktop pour /dev/null o chmod 0 le site gnome-keyring-daemon ). En fait, le softlinking vers /dev/null a cessé de fonctionner pour moi dans GNOME 3.16.

Le mérite revient à nus .

Je ne peux pas parler pour les versions d'Ubuntu autres que Trusty - et GNOME est une cible tellement mouvante que vous pouvez garantir que chaque version sera différente - mais c'est ce que j'ai trouvé pour fonctionner de la manière la plus fiable :

mkdir -p ~/.config/autostart
cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/
echo "X-GNOME-Autostart-enabled=false" >> ~/.config/autostart/gnome-keyring-ssh.desktop

Le démarrage de la session sous Unity, au moins, et très probablement sous GNOME3 aussi, est bizarre : il exécutera Upstart scripts à partir de /usr/share/upstart/sessions/ et exécute ensuite toutes les entrées du bureau de démarrage automatique sous /etc/xdg/autostart y gnome-keyring et beaucoup d'autres choses se trouvent dans les deux (et il exécute probablement des choses en /usr/share/upstart/xdg/autostart Je ne l'ai pas testé).

El gnome-keyring-ssh L'entrée upstart vérifiera cela X-GNOME-Autostart-enabled=false dans l'entrée .desktop locale du système ou de l'utilisateur, puis revenez en arrière. ssh-agent La session se déroulera. Le système gnome-keyring-ssh va alors démarrer à partir de /etc/xdg/autostart sauf si vous avez une entrée correspondante dans le démarrage automatique de votre utilisateur local, auquel cas elle sera exécutée à la place.

Avant, il suffisait d'avoir ce enable=false dans le démarrage automatique local, mais récemment (depuis mai 2016, soit plus de deux ans après le début de la période LTS de Trusty), ce comportement a changé et vous avez besoin de quelque chose qui ressemble à une entrée complète. Je suis toujours en train d'enquêter sur le jeu précis de clés nécessaires, et sur la mise à jour du paquet incriminé responsable.

Pourquoi les gens de GNOME ne se sont pas contentés de passer par l'agent de clés OpenSSH ? personne ne sait . Vous pourriez leur suggérer d'adopter un comportement plus raisonnable. dans cette entrée de Bugzilla .

Je finis toujours par désinstaller gnome-keyring.

sudo apt-get remove gnome-keyring

Il s'avère que si vous utilisez plusieurs clés (plus de trois), vous ne pouvez pas vraiment vous connecter à des hôtes qui limitent les tentatives à trois... Aussi, gnome-keyring nomme les clés différemment que lors de l'utilisation de ssh-add donc je ne sais pas quelle phrase de passe utiliser.

Désinstallation de gnome-keyring pourrait casser beaucoup de choses sur GNOME, je ne le saurais pas car j'utilise Kubuntu. Sur Kubuntu tout ce qui disparaît en plus sont python-ubuntu-sso-client y ubuntu-sso-client .

Une façon agréable et propre de désactiver uniquement le composant ssh-agent de gnome-kerying :

gconftool-2 --set --type bool /apps/gnome-keyring/daemon-components/ssh false

Je confirme que le script

#!/usr/bin/python
import gnomekeyring
gnomekeyring.unlock_sync(None,"mypassword");

résout le problème dans 16.04, amd64. Le script peut être sauvegardé en tant que ukr.py alors chmod +x ukr.py puis ajoutez ukr.py comme application de démarrage dans gnome-session-properties . Le module (supplémentaire) gnomekeyring est installé via

sudo apt-get install python-gnomekeyring