I'm wondering if it is possible to use gnome-keyring-daemon without X. Normally it will present a graphical prompt in order to acquire a password for the keyring; is there a way around this? I'd like to be able to use ubuntu one without having to start a graphical session and type in my password.

4 Answers 4


You can use pam_gnome_keyring.so to start and unlock the daemon. GDM already does this; for login, you must configure it manually.

Add these lines to /etc/pam.d/login:

auth     optional  pam_gnome_keyring.so
session  optional  pam_gnome_keyring.so auto_start

If you log in without a password (SSH with Kerberos or public keys), this may work: (I haven't tested it)

echo -n "mypassword" | gnome-keyring-daemon --login

(You still need the daemon to be running - either started via PAM or with --daemonize.)

  • Second case is the case in my case. That (undocumented?) --login option is pretty useful, though I sure wouldn't want to keep my unhashed password in a script or put it on a command line. reading in unechoed mode from within a (non-shell-language) script that then passes that input to the spawned daemon would probably be a good way to do this. I should only have to start this process once per boot, so it makes sense to type in the password; I just need to be able to do it at the command line instead of via the GTK dialog.
    – intuited
    May 14, 2010 at 21:25
  • 1
    err.. nevermind, it's documented by gnome-keyring-daemon --help. I just checked the manpage and /usr/share/doc.
    – intuited
    May 14, 2010 at 22:32
  • 2
    @intuited: Well, then do something like this: read -rsp "Password: " pass; echo -n "$pass" | gnome-keyring-daemon --login in a script. May 15, 2010 at 10:55
  • 1
    Actually yeah, that would work; I was forgetting that echo was a builtin.
    – intuited
    May 15, 2010 at 18:52
  • 1
    In reply to old comment from @intuited: gnome-keyring-daemon --help gives me a good overview, but man gnome-keyring-daemon just contains a short description on the program itself but to no arguments.
    – feeela
    Jun 19, 2012 at 18:53


The requisite jobs of installing svn with keyring support and installing the Collabnet keyring_tool application are already performed for our Linux servers.

1) Configure SVN client to use keyring:

1.1) Edit ~/.subversion/config

password-stores = gnome-keyring

1.2) Edit ~/.subversion/servers

store-passwords = yes
store-plaintext-passwords = no

2) Create a keyring for your password. You will be prompted to create a new password to unlock the keyring; this may be anything you wish:

keyring_tool --create=svn

3) Set the new keyring as the default:

keyring_tool --setdef=svn

4) In .bash_profile or .bash_login (assuming you are using bash as your terminal)

    if [ -e /usr/bin/gnome-keyring-daemon ]; then
      if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
        # Create dbus transport link for SVN to talk to the keyring.
        eval `dbus-launch --sh-syntax`

        # Start the keyring daemon.
        # The use of export here captures the GNOME_KEYRING_PID, GNOME_KEYRING_SOCK
        # env values echoed out at startup.
        export `/usr/bin/gnome-keyring-daemon`

5) In .bash_logout

    # Kill the message bus established for SVN / Keyring communication
    if [ ! -z "`kill -0 $DBUS_SESSION_BUS_PID 2>&1`" ]; then
      kill $DBUS_SESSION_BUS_PID > /dev/null 2>&1

    # Kill the Gnome Keyring Daemon prior to logout.
    if [ ! -z "`kill -0 $GNOME_KEYRING_PID 2>&1`" ]; then
      kill $GNOME_KEYRING_PID > /dev/null 2>&1


I ran into a similar problem while trying to establish a hassle free way to ensure authorized user access to certain SVN repos at work. Basically we had to force credential checking every time a user accesses the server so even the svn update command would require authentication. Clearly plain text password storage was out so with a little research I came upon using the gnome-keyring as a way around harassing our user base with constant authentication requests while still keeping unauthorized users out of repositories they should not have access to view.

Much of our day to day work is done via ssh tunnels into a RedHat server w/o X support so I had to find a way around the X11 support. After some searching I managed to find the way around it here:

Source Material


They key here is using the Collabnet keyring_tool to create a keyring without the gnome-keyring-manager client and establishing the dbus-launch yourself rather than letting SVN handle the setup. SVN uses DBUS to connect to the gnome-keyring-daemon and affect the overall authentication. By manually starting and tearing down the dbus session with -sh-syntax you avoid trying to connect to an X client on dbus startup. If you just start the gnome-keyring-daemon and attempt to use SVN it will still prompt you for your keyring password but then will prompt you for your SVN credentials as well. The dbus will fail when SVN tries to start it because of the lack of an X client; apparently SVN does not use any special flags when starting the dbus.

  • Thank you so much for this, have been pulling my hair out trying to get rid of a "CRITICAL **: Error communicating with gnome-keyring-daemon" error on git pull. Your changes to ~/.profile and ~/.bash_logout fixed that... Still not saving passwords but I'm one step closer! (Ubuntu 16.04.1 LTS)
    – user201350
    Aug 22, 2016 at 4:31

I had some success with getting mysql-workbench to work with gnome-keyring in an x-forwarded SSH session. This was an account that used publickey authentication (no password).

I used dbus-run-session to achieve this once connected to the ssh session:

dbus-run-session bash -c 'GNOME_KEYRING_CONTROL=1 mysql-workbench --verbose'

hopefully this information is useful to someone!

  • This helped one step closer to having mysql-workbench run inside a docker container and export the display to my mac host. When I try to add a password to a new connection, it shows me the prompt, but after typing the pwd, I get: "Failed to execute program org.freedesktop.secrets: Operation not permitted". Any clues? Aug 14, 2019 at 22:31

First, what you really want to be doing is running Ubuntu One strictly from command-line. Take a look through the Ubuntu One FAQ. The FAQ says it's not presently possible, but there are some CLI tools like u1sdtool and u1sync. There's also a set of FAQs on Ubuntu One at Launchpad; the content may be the same as the earlier wiki.ubuntu.com link.

Regarding your actual question about gnome-keyring-daemon, the FAQ suggests (1) setting auto-login and (2) synchronizing your keyring password with your login password. This would (in theory) avoid the password prompt, but it would require at least a basic X-session to be running.

There's an Ubuntu One bug/wishlist on Launchpad that requests making it easier to handle headless systems. Apparently building from source is recommended for a lightweight install (to avoid the need for all the GUI libraries and such). This comment is old, but particularly interesting:

The problem is that we use python-gnomekeyring. For us to support headless, we'll have to switch to python-keyring, and handle storing tokens somewhere other than gnome-keyring on headless displays. However, none of this is going to happen for the Karmic packaging as it is frozen, and this change wouldn't be acceptable in an SRU.

For Lucid, we should have a more robust authenticaton service, which should allow us to support headless displays better.

I can't tell if this "more robust authentication service" was actually put in place for Lucid; based on the package dependencies, it seems the Ubuntu One client is still dependent on python-gnomekeyring.

You must log in to answer this question.

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