mjhjmtu

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:
https://ubuntuforums.org/showthread.php?t=1059023

https://ask.fedoraproject.org/en/question/45246/error-communicating-with-gnome-keyring-daemon-in-ssh-session/


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
 fi
 fi
fi

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.

Sources:
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
 do
 export $LINE
 done <<< $(gnome-keyring-daemon --start --components=gpg,pkcs11,secrets,ssh)
fi

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?