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?