gnome keyring no longer acts as ssh agent on login

[Mikel Ward]

I was using Ubuntu 8.10 with pam_gnome_keyring configured to start in /etc/pam.d/gdm.

This used to start GNOME Keyring at login and work as my SSH agent, meaning I could run ssh <remote server> and I didn't need to re-enter my passphrase.

After upgrading to Ubuntu 9.04, this is broken.

Now, ssh-agent gets started via my ~/.bash_profile, which only happens if SSH_AUTH_SOCK is unset, and then I am asked to enter my SSH key's passphrase due to ssh-add also being conditionally started in ~/.bash_profile if ssh-add -l shows not keys already added to the ssh agent.

[Mikel Ward (mikelward)]

Actually, it's something stranger. I think it might be starting but not unlocking my SSH key automatically.

Need to investigate further.

$ echo $SSH_AUTH_SOCK
/tmp/keyring-6gJinp/socket.ssh
$ echo $SSH_AGENT_PID
3971
$ ps -ef | grep keyring
mward 3930 1 0 11:21 ? 00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login
$ sudo lsof -p 3930 | grep '/tmp'
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/mward/.gvfs
      Output information may be incomplete.
gnome-key 3930 mward 7u unix 0xf50c5c00 9417 /tmp/keyring-6gJinp/socket
gnome-key 3930 mward 16u unix 0xf52ce000 10327 /tmp/orbit-mward/linc-f5a-0-3921dd1d5f951
gnome-key 3930 mward 17u unix 0xf52ce8c0 10330 /tmp/orbit-mward/linc-f5a-0-3921dd1d5f951
gnome-key 3930 mward 18u unix 0xf52cea80 10331 /tmp/keyring-6gJinp/socket.ssh
gnome-key 3930 mward 19u unix 0xf52cec40 10333 /tmp/keyring-6gJinp/socket.pkcs11
$ ps -fp 3971
UID PID PPID C STIME TTY TIME CMD
mward 3971 1 0 11:21 ? 00:00:00 ssh-agent
$ cat ~/.profile
    if test -z $SSH_AUTH_SOCK
    then
        if type ssh-agent >/dev/null 2>/dev/null
        then
            eval $(ssh-agent)
        fi
    fi
    if test -n $SSH_AUTH_SOCK
    then
        if type ssh-add >/dev/null 2>/dev/null
        then
            if ! ssh-add -l >/dev/null
            then
                ssh-add
            fi
        fi
    fi

[Sebastien Bacher (seb128)]

Thank you for your bug report. Not confirming the issue but it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

[Mikel Ward (mikelward)]

Initially I wondered if Ubuntu had changed the order of the X login scripts to invoke Bash before GNOME Keyring, which is why I didn't report the bug upstream.

I still suspect that's the case, but that shouldn't matter: if the GNOME Keyring is being started properly via PAM, then that should happen before Bash is started, and thus SSH_AUTH_SOCK should be set before my ~/.profile is sourced.

The ssh-agent process (pid 3971) above suggests that GNOME Keyring isn't running (or at least hasn't exported the SSH_AUTH_SOCK environment variable) at the time Bash is invoked, so the problem is probably in GNOME Keyring.

Will investigate further when I find the time.

[Mikel Ward (mikelward)]

Lots of weirdness.

$ cat ~/.xsession-errors
/etc/gdm/Xsession: Beginning session setup...
Agent pid 12447
Identity added: /home/mward/.ssh/id_rsa (/home/mward/.ssh/id_rsa)
Warning: Only changing the first 3 of 32 buttons.
Setting IM through im-switch for locale=en_AU.
Start IM through /etc/X11/xinit/xinput.d/all_ALL linked to /etc/X11/xinit/xinput.d/default.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
I: caps.c: Dropping root privileges.
I: caps.c: Limited capabilities successfully to CAP_SYS_NICE.
N: main.c: Called SUID root and real-time and/or high-priority scheduling was requested in the configuration. However, we lack the necessary privileges:
N: main.c: We are not in group 'pulse-rt', PolicyKit refuse to grant us the requested privileges and we have no increase RLIMIT_NICE/RLIMIT_RTPRIO resource limits.
N: main.c: For enabling real-time/high-priority scheduling please acquire the appropriate PolicyKit privileges, or become a member of 'pulse-rt', or increase the RLIMIT_NICE/RLIMIT_RTPRIO resource limits for this user.

(gnome-settings-daemon:12699): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed

(gnome-settings-daemon:12699): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
GNOME_KEYRING_SOCKET=/tmp/keyring-ZC3meK/socket
SSH_AUTH_SOCK=/tmp/keyring-ZC3meK/socket.ssh
...

And then looking in /etc/gdm/Xsession...

# good for debugging where things went wrong
echo "$0: Beginning session setup..."

# First read /etc/profile and .profile
test -f /etc/profile && . /etc/profile
test -f "$HOME/.profile" && . "$HOME/.profile"
# Second read /etc/xprofile and .xprofile for X specific setup
test -f /etc/xprofile && . /etc/xprofile
test -f "$HOME/.xprofile" && . "$HOME/.xprofile"

Why is it sourcing my ~/.profile? That's wrong!

$ head ~/.profile | grep echo
echo "$(date) profile SSH_AGENT_PID=$SSH_AGENT_PID SSH_AUTH_SOCK=$SSH_AUTH_SOCK gnome-keyring=$(pgrep -d , -f gnome-keyring) ssh-agent=$(pgrep -d , -f ssh-agent)" >> $HOME/.sh.log
$ head ~/.shrc | grep echo
echo "$(date) shrc SSH_AGENT_PID=$SSH_AGENT_PID SSH_AUTH_SOCK=$SSH_AUTH_SOCK gnome-keyring=$(pgrep -d , -f gnome-keyring) ssh-agent=$(pgrep -d , -f ssh-agent)" >> $HOME/.sh.log
$ cat ~/.sh.log
Mon May 18 09:39:45 EST 2009 profile SSH_AGENT_PID= SSH_AUTH_SOCK= gnome-keyring=12408 ssh-agent=4198
Mon May 18 09:40:31 EST 2009 shrc SSH_AGENT_PID=12447 SSH_AUTH_SOCK=/tmp/keyring-ZC3meK/socket.ssh gnome-keyring=12408 ssh-agent=4198,12447
$ ps -fp 4198
UID PID PPID C STIME TTY TIME CMD
mward 4198 1 0 09:05 ? 00:00:00 ssh-agent
$ ps -fp 12408
UID PID PPID C STIME TTY TIME CMD
mward 12408 1 0 09:39 ? 00:00:00 /usr/bin/gnome-keyring-daemon --daemonize --login

I logged in at 9:39, so the ssh-agent is from my previous log in.

It also shows that GNOME Keyring Daemon is already started before my ~/.profile is sourced, but that SSH_AUTH_SOCK is unset.

So the /etc/gdm/Xsession stuff is arguably a bug, and GNOME Keyring Daemon should probably be setting SSH_AUTH_SOCK as soon as it's started via PAM, but it doesn't look like it is (or something is nuking the environment).

[Mikel Ward (mikelward)]

Oh, and the time difference between profile and shrc is deliberate: I waited for over 30 seconds before typing my passphrase into the X11 ssh-askpass dialog.

[Mikel Ward (mikelward)]

After disabling GNOME Keyring Daemon from GNOME Startup Applications, it now does this:

Mon May 18 10:21:23 EST 2009 profile SSH_AGENT_PID= SSH_AUTH_SOCK= gnome-keyring=19685 ssh-agent=4198,12447
Mon May 18 10:22:04 EST 2009 shrc SSH_AGENT_PID=19724 SSH_AUTH_SOCK=/tmp/ssh-vNoOL19723/agent.19723 gnome-keyring=19685 ssh-agent=4198,12447,19724

SSH_AUTH_SOCK now points to ssh-agent rather than GNOME Keyring daemon. This suggests g-k-d is (now?) split into two halves, and it's only initializing SSH_AUTH_SOCK after the second half starts, further that the GNOME startup applications are running after /etc/gdm/Xsession sources ~/.profile.

[Mikel Ward (mikelward)]

The best workaround I can think of is to change my ~/.profile to this:

    if test -z "$GNOME_KEYRING_PID"
    then
        if test -z "$SSH_AUTH_SOCK"
        then
            if type ssh-agent >/dev/null 2>/dev/null
            then
                eval $(ssh-agent)
            fi
        fi
        if test -n "$SSH_AUTH_SOCK"
        then
            if type ssh-add >/dev/null 2>/dev/null
            then
                if ! ssh-add -l >/dev/null
                then
                    ssh-add
                fi
            fi
        fi
    fi

But that won't account for GNOME Keyring being started in --login mode in PAM but not being started in --start mode via GNOME Session.

[Mikel Ward (mikelward)]

This is broken even worse in XFCE.

GNOME Keyring is obviously being started via GDM in --login mode, but then the --start part is not being done by default due to /etc/xdg/autostart/gnome-keyring-daemon.desktop having OnlyShowIn=GNOME.

After I remove that line, I can see it's printing
    GNOME_KEYRING_SOCKET=/tmp/keyring-7zOY9J/socket
    SSH_AUTH_SOCK=/tmp/keyring-7zOY9J/socket.ssh

in my ~/.xsession-errors, but $SSH_AUTH_SOCK is set to something like /tmp/ssh-qHvvfg4613/agent.4613, I think due to /etc/xdg/xfce4/xinitrc:115
    if test -z "$SSH_AGENT_PID" -a "$sshagent" -a "x$sshagent" != "xno"; then

which should be testing SSH_AUTH_SOCK, not SSH_AGENT_PID, and perhaps because GNOME Keyring Agent can't modify XFCE's environment in the way it can modify GNOME environment?

The workaround I've found for that is to put:
    eval $(gnome-keyring-daemon --start)
    export SSH_AUTH_SOCK

in my ~/.profile inside
    if test -n "$GNOME_KEYRING_PID"

This is truely nasty stuff.

[Sebastien Bacher (seb128)]

the issue doesn't concern a sru upload untagging

[Lars Volker (lv)]

gnome-keyring-daemon does not export SSH_AUTH_SOCK here at all. I already disabled ssh-agent in Xsession.options and after that also disabled it in xinitrc, which was trying to start it as well. After that, when there was no ssh-agent interfering with gnome-keyring-daemon, SSH_AUTH_SOCK was not set at all.

[Forest (foresto)]

Lars, gnome-keyring-daemon does not set SSH_AUTH_SOCK directly. To get it to work, these things have to happen:

1. Run gnome-keyring-daemon --login
This starts the daemon, and is happening automatically on my xubuntu installation.

2. Run gnome-keyring-daemon --start
This loads your ssh keys into the already-running daemon, and prints on standard output the shell commands needed to set SSH_AUTH_SOCK.

3. Execute the shell commands that get printed by that last command in a parent shell whose environment variables will be inherited by the processes in your X session. This is how SSH_AUTH_SOCK actually gets set. It is what Mikel is doing in his workaround described in post #8.

#3 is definitely not happening in my xubuntu installation. I don't think #2 is happening either, because if it was, I would expect SSH_AUTH_SOCK to be pointing at the gnome-keyring socket (it isn't even set) or else to see the commands for setting it in ~/.xsession-errors (which I don't).

[Forest (foresto)]

More details on how get environment variables get set by gnome-keyring-daemon:

http://live.gnome.org/GnomeKeyring/RunningDaemon

It seems certain session managers are supposed to make it unnecessary to execute the output of "gnome-keyring-daemon --start".

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.