我在 RHEL/CentOS 7 服务器上有一个 X-MATE 桌面环境。它曾经是 Gnome 3，但由于各种原因被替换。
当会话启动时，gnome-keyring 处于活动状态并控制环境变量 SSH_AUTH_SOCK 等。这样做的结果是来自 Mate 终端的出站连接不起作用。如果我取消设置 ssh 套接字变量，一切都很好。
我在这个问题上工作了很长时间，尝试了很多方法，包括向Redhat公司请求帮助。他们无法找到原因，但可能是他们还没有完全理解。
最初设置时，从进程树可以清楚地看出，gnome-keyring 是作为参与设置桌面环境的其他 x-mate 进程之一的子进程启动的。
我的第一个更改是在 /etc/xdg/autostart/gnome-keyring-ssh.desktop、gnome-keyring-secrets 中的文件中设置 X-MATE-Autostart=false、X-GNOME-Autostart=false 和 Hidden=true。桌面和 gnome-keyring-pkcs11.desktop。此更改没有效果。另外，我尝试在 $HOME/.config/autostart 中添加相同的三个文件，其中包含两行条目 [Desktop Entry] Hidden=true
也没有什么区别。
最后，我在 /etc/pam.d/ 的各种文件中找到了对 gnome-keyring 的引用，并认为它可能是由某些登录进程启动的。我评论了所有这些行。还是不行。
我现在看到的是 gnome-keyring 进程仍然存在，但它是 PID 1 systemd 的子进程。我看到它以这种方式启动的唯一方法是通过在 DBUS 中启用。但我对DBUS了解不多。
当然，如果我终止 gnome keyring 进程，ssh 套接字就会消失，出站 ssh 就会工作。
尝试在 DBUS 中禁用 gnome-keyring 是否明智或符合逻辑？如果是的话，那是怎么做到的？否则我想过完全卸载 gnome-keyring 包，但依赖关系使这成为不可能。
我们根本不使用 gnome-keyring。但我们似乎无法阻止它。
我发现了10年前的这个帖子： https://ubuntuforums.org/showthread.php?t=1655397 它探讨了完全相同的问题。 “解决方案”是禁用 /usr/share/dbus-1/services/org.freedesktop.secrets.service 中的 Exec= 我尝试了这个，但我认为重新启动是必要的（除非可以进行其他激活），这就是对于这位主人来说，正确的割草并不容易。尽管如此，我认为在 /etc/dbus-1/session.d/ 中可以进行覆盖，但无法弄清楚如何进行。
欣赏想法、创造性的解决方法或解决方案？
答案1
你是对的，gnome-keyring-daemon是由 dbus 启动的。相关文件位于/usr/share/dbus-1/services/org.freedesktop.secrets.serviceopensuse 上（不确定 ubuntu 是否如此，但可能是相同的）。因此，您可以简单地注释掉上面文件中的 Exec 行。不幸的是，我不知道如何从用户会话中覆盖 dbus 服务文件（我想这应该是可能的，因为 kde 启动了自己的守护进程）。
经过更多调查后，您可以在默认$XDG_DATA_HOME/dbus-1/services位置$XDG_DATA_HOME指定用户 dbus 服务文件~/.local/share。但是，当覆盖时仅使用空 Exec 行是不够的，因为 dbus 将仅使用系统文件，因此您需要提供一些其他服务。而且，似乎它被作为扁平包的一部分org.freedesktop.secret.service的依赖项拉进来。xdg-desktop-portal因此，禁用 xdg-desktop-portal 服务也可能有效。
我不得不说，关于此问题的矛盾且不正确的文档令人愤怒。