1

I have an X-MATE desktop environment on a RHEL/CentOS 7 server. It used to be Gnome 3 but it was replaced for various reasons.

When a session is started the gnome-keyring is active and controls the environment variables SSH_AUTH_SOCK among others. The effect of this is that outbound connections from a Mate terminal don't work. If I unset the ssh socket variable it is all fine.

I have worked on this for a long time and tried many things including requesting assistance from Redhat Inc. They are unable to find the cause but it may be that they have not fully understood.

When initially setup it was clear from the process tree that the gnome-keyring was started as a child of one of the other x-mate processes involved in setting up the desktop environment.

My first change was to set X-MATE-Autostart=false, X-GNOME-Autostart=false and Hidden=true in the files in /etc/xdg/autostart/ gnome-keyring-ssh.desktop, gnome-keyring-secrets.desktop, and gnome-keyring-pkcs11.desktop. This change had no effect. Additionally I tried in $HOME/.config/autostart adding the same three files with a two line entry [Desktop Entry] Hidden=true

Also makes no difference.

Lastly I found references to gnome-keyring in various files in /etc/pam.d/ and thought it might be started by some of the login processes. I commented all those lines. Still doesn't work.

What I now see is that gnome-keyring process is still present, however it is a child of PID 1, systemd. The only way I see it started that way is via being enabled in DBUS. But I don't know much about DBUS.

Of course if I kill the gnome keyring process the ssh socket goes away and the outbound ssh works.

Is it sensible or logical to try and disable gnome-keyring in DBUS? If so how is that done? Otherwise I have thought of uninstalling the gnome-keyring package altogether but the dependencies make this impossible.

We don't use the gnome-keyring at all. But we can't seem to stop it.

I have found this thread from 10 years ago: https://ubuntuforums.org/showthread.php?t=1655397 It explores exactly the same problem. The 'solution' was to disable an Exec= in the /usr/share/dbus-1/services/org.freedesktop.secrets.service I tried this but I think a reboot is necessary (unless some other activation is possible) and that's not easy for this host right mow. Still, I thought an override would be possible in /etc/dbus-1/session.d/ but can't work out how.

Appreciate ideas, or creative workarounds, or a solution?

1 Answer 1

0

You're correct that gnome-keyring-daemon is started by dbus. The relevant file is /usr/share/dbus-1/services/org.freedesktop.secrets.service on opensuse (not sure about ubuntu, but likely the same). So you could simply comment out the Exec line in the file above. Unfortunately I don't know of a way to overwrite dbus service files from a user session (I guess it should be possible because kde starts their own daemon).

After some more investigation, you can specify user dbus service files in $XDG_DATA_HOME/dbus-1/services where $XDG_DATA_HOME is ~/.local/share by default. However, when overwriting just using an empty Exec line is not sufficient, because dbus will then just use the system file, so you need to provide some other service. Also it seems that the org.freedesktop.secret.service is being pulled in as a dependency of xdg-desktop-portal which is part of flatpack. So disabling the xdg-desktop-portal service might also do the trick.

The contradictory and incorrect documentation floating around about this is infuriating I have to say.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.