My use case is that I have a headless server that software development is performed on. I ussually enable X11 forwarding for the SSH connections to it, but I can't for distant locations with slow connections.
I need secure storage and caching for my git credentials since I regularly work with 18-20 repositories in a tree, so I'm using git-credential-gnome-keyring as the the git credential.helper, which communicates using the libgnome-keyring to the gnome-keyring-daemon. To test solutions, I setup a PC with a monitor, confirmed the keyring worked by default on the system, then tried it with SSH. It works with X11 forwarding, but does not work without it.

When I'm connected without X11 forwarding, the following error results when the keyring is queried, and the tool falls back to prompting on the command-line:

** (process:18305): CRITICAL **: Error communicating with gnome-keyring-daemon

Investigation reveals that the base problem is that gnome-keyring-daemon is expecting connections to use dbus to talk to it. The dbus isn't started if there's no X11 session, so there's no common dbus bus for the gnome-keyring-daemon and libgnome-keyring to connect to.

I've found two solutions others have posted to this problem, though neither works properly for me.

  1. Get a DBUS port from an existing session that uses X11
  2. Manually launch a new DBUS port

When attaching to an existing DBUS port, the base concept is to find the PID of an existing login session, dump the environment for that PID from the procfs, search it for the DBUS_SESSION_BUS_ADDRESS, and export it in the current environment. Since this is the variable used to publish the DBUS bus being used by everything in the sessions, setting this should allow everything in the session to communicate on a common DBUS bus, though it's the bus associated with a different session.
Sources here:


Code added to my .bashrc being executed on ssh login:

if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] ; then
    local myPID=`pgrep "(.*session|fluxbox)" | head -n1`
    if [ -n "$myPID" ] ; then
        local myVar=`cat /proc/${myPID}/environ | grep -z "^DBUS_SESSION_BUS_ADDRESS=" | sed -e 's/DBUS_SESSION_BUS_ADDRESS=//'`
        if [ -n "$myVar" ] ; then
            export DBUS_SESSION_BUS_ADDRESS=$myVar

The second method, manually launching DBUS for the session, involves using dbus-launch to create a new session and set the DBUS_SESSION_BUS_ADDRESS for the environment, then starting the gnome-keyring-daemon with all the necessary services so it will see the DBUS bus address we've created rather than an empty bus address. This solution may or may not require gnome-keyring-daemon be changed to run one instance per session rather than one instance per system, but it's not clear.
Starting with number 8 : https://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh-session

How to modify a dbus service's "Exec" line without losing the changes in case of upgrade
Code added to my .bashrc being executed on ssh login:

# then DBUS wasn't started for this session and needs to be
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] ; then
    # start a new dbus session and make sure the variables are exported (automatic output)
    eval `dbus-launch --sh-syntax`

    # make sure gnome-keyring-daemon is using all the necessary components (it may not be by default)
    # Capture the output, which is a series of variable setting commands, one on eachline, and
    # export them while setting them
    while read -r LINE
        export $LINE
    done <<< $(gnome-keyring-daemon --start --components=gpg,pkcs11,secrets,ssh)

Both solutions give the same failing result. Instead of immediately producing the error indicating the gnome-keyring-daemon can't be communicated with, the process hangs for a while and then produces this output:

Gkr-Message: secret service operation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

** (process:31155): CRITICAL **: Error communicating with gnome-keyring-daemon

I'm not clear on how the gnome-keyring-daemon is interacting with DBUS, but its clear from the second set of error results that it's not reachable via a newly created DBUS bus, or cross-process on a different DBUS bus. Some of what I've found suggests the gnome-keyring-daemon might need the DBUS started before it, but it's unclear whether that's the case for the usage (libgnome-keyring) or the daemon.

How do I get this working?

  • indeed the dbus session need to be started before the user keyring (daemon) also when you use x11 forwarding you are using the local keyring not the remote one...
    – intika
    Commented May 26, 2019 at 1:48
  • As the first approach showed, I did start the dbus session before the keyring daemon was started. And you're saying that when I execute a command that makes use of the gnome-key-ring daemon on my remote system, it's making a connection via the $DISPLAY socket back to my source system to connect to the dbus session there? That seems extremely unlikely, but I don't know enough about it to disagree fully. Dbus isn't a graphical tool, it's an inter-process communication tool that happens to be used a lot by graphical applications.
    – mtalexan
    Commented May 31, 2019 at 17:06
  • Just spitballing here, but have you tried using xvfb to "fake" an xsession. It might work if you got it to run (and finish initializing) and exported the DISPLAY var such that dbus knows an Xserver is running Commented Jun 2, 2019 at 6:47

1 Answer 1


This may be a stupid answer ... but, gnome-keyring need access to a X11 session, at least to prompt your for the master key. So, it's just impossible to make it run , by design ... isn't it ?

EDIT: Maybe not that impossible. See this post, looks similar to your problem:

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .