Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question

3 Answers 3

up vote 6 down vote accepted

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.)

share|improve this answer
    
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 '10 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 '10 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. –  grawity May 15 '10 at 10:55
    
Actually yeah, that would work; I was forgetting that echo was a builtin. –  intuited May 15 '10 at 18:52
    
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 '12 at 18:53

Synopsis

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

[auth]
password-stores = gnome-keyring

1.2) Edit ~/.subversion/servers

[global]
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`
      fi
    fi

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
    fi

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

Background

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

http://support.wandisco.com/index.php?/Knowledgebase/Article/View/362/17/how-to-setup-encrypted-svn-password-storage-using-gnome-keyring-in-an-ssh-session

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.