Ubuntu
gnome-keyring package

no ssh-agent after resume from hibernate

Bug #268141 reported by Felipe Figueiredo
28
This bug affects 3 people
Affects Status Importance Assigned to Milestone
GNOME Keyring
Fix Released
Critical
gnome-keyring (Fedora)
Fix Released
Low
gnome-keyring (Ubuntu)
Fix Released
Medium
Unassigned
Ubuntu ubuntu-9.04-beta
Nominated for Hardy by Felipe Figueiredo
Nominated for Intrepid by Felipe Figueiredo

Bug Description

Binary package hint: gnome-keyring

When gconf key /apps/gnome-power-manager/lock/gnome_keyring_suspend is set to true, and GNOME Keyring's password is blank, gnome-keyring crashes with a failed assertion when attempting to hibernate the system. The same thing happens when /apps/gnome-power-manager/lock/gnome_keyring_suspend is set to true, during an attempt to suspend.

TEST CASE:
1. On a system where suspend works, set /apps/gnome-power-manager/lock/gnome_keyring_suspend to true.
2. SSH into a known system using a public key that is protected by a passphrase. Note that GNOME Keyring remembers the passphrase (or prompts you with the GUI). Alternatively, run 'ps aux | grep gnome-keyring-daemon' and note that there is a process by the name of gnome-keyring-daemon running.
3. Suspend the system (using Fast-User-Switch-Applet)
4. Resume the system
5. Attempt #2 again. Notice that SSH now prompts you for a passphrase from within the terminal, and it is not remembered. Alternatively, run 'ps aux | grep gnome-keyring' and note that gnome-keyring-daemon has disappeared from the processes list.

See original description
Revision history for this message
In , Julian (julian-redhat-bugs) wrote :

Description of problem:
After resume from either suspend or hibernate, seahorse agent does not ask for
keyring password, so for instance to commit to Fedora cvs I have to enter the
ssh keys password a few times. Before the resume a window pops out and the
password is required only once.

Version-Release number of selected component (if applicable):
2.22.2-1.fc9

How reproducible:
every time

Steps to Reproduce:
1. suspend/hibernate the machine
2. resume
3. do something that requires entering ssh key password

Actual results:
password prompt appears in the console every time ssh key is needed

Expected results:
a window pops out and asks for password only once

Additional info:
I don't know if it's related, but ssh-add does not work either (says “Could not
open a connection to your authentication agent.”), so there is really no way to
avoid the need for entering the password several times, apart from reboot.

Revision history for this message
In , Julian (julian-redhat-bugs) wrote :

I think you need to do something that requires entering ssh key password before suspend as well.

Revision history for this message
Felipe Figueiredo (philsf) wrote :

Related bugs (not dups): bug #99065 and #70752

Revision history for this message
Andreas Moog (ampelbein) wrote :

Reassigning to seahorse-plugins, this is the package where seahorse-agent is in intrepid.

Changed in seahorse:
importance: Undecided → Medium
Revision history for this message
Andreas Moog (ampelbein) wrote :

Could you perhaps try with intrepid? I think upstream won't accept any bugs from older versions anymore, now that 2.24.0 is out. Also, please check if ssh-agent runs on the same pipe after resuming your pc.

Changed in seahorse-plugins:
status: New → Incomplete
Revision history for this message
Felipe Figueiredo (philsf) wrote :

I originally reported this bug against seahorse, since it appears as argument to ssh-agent in the processes list.

I'd like to correct the testcase. Although it happened that seahorse died when I decided to post the bug, I cannot reproduce it, therefore I'm forced to attribute this event to chance.

I confirm that the ssh-agent is not functional after hibernate, and now I have a new test-case that I can reproduce at will.

Test case:
1- ps x | egrep "agent|keyring"
2- hibernate and thaw
3- ps x | egrep "agent|keyring"

Step 1 returns:
 7174 ? Ss 0:00 /usr/bin/ssh-agent /usr/bin/seahorse-agent --execute sh /home/philsf/.xsession
 7243 ? Ss 0:00 /usr/bin/seahorse-agent --execute sh /home/philsf/.xsession
 7291 ? SL 0:00 /usr/bin/gnome-keyring-daemon

Step 3 returns:
7174 ? Ss 0:00 /usr/bin/ssh-agent /usr/bin/seahorse-agent --execute sh /home/philsf/.xsession
7243 ? Ss 0:00 /usr/bin/seahorse-agent --execute sh /home/philsf/.xsession
9489 pts/2 S+ 0:00 egrep agent|keyring

So, gnome-keyring-daemon is the process that dies. I'm assigning the bug to gnome-keyring package. This is gnome-keyring 2.22.2-0ubuntu1.

The relevant directories in /tmp (/tmp/ssh-* and /tmp/keyrin*) are not deleted, but the pipe can't be reused without restarting gnome-keyring-daemon, and there's no documentation on how to restart it reusing the existing socket for this reason I can't use the workaround in bug #99065.

Also, why does gnome-keyring-daemon crashes in the first place? The following is the only relevant line in $HOME/.xsession-errors

** Message: another SSH agent is running at: /tmp/ssh-UZKukL7062/agent.7062

This appears to be the same message I get from g-k-d, if I try to start it manually after hibernating. The process daemonizes, but there's no ssh-agent to be used:

$ ssh localhost
Error reading response length from authentication socket.
Enter passphrase for key '/home/philsf/.ssh/id_dsa':

Changed in seahorse-plugins:
status: Incomplete → New
Revision history for this message
Felipe Figueiredo (philsf) wrote :

I found that to use a workaround to restart gnome-keyring-daemon from command line in a way to reuse the existing socket: the env var GNOME_KEYRING_TEST_PATH. This var should be set to the /tmp/keyring-XXXXXXXX that was previously in use.

For example:
GNOME_KEYRING_TEST_PATH=/tmp/keyring-pw7JIX/ gnome-keyring-daemon
** Message: another SSH agent is running at: /tmp/keyring-pw7JIX/ssh
GNOME_KEYRING_SOCKET=/tmp/keyring-pw7JIX//socket
SSH_AUTH_SOCK=/tmp/keyring-pw7JIX//ssh
GNOME_KEYRING_PID=24788

When I next try to use a ssh key, it asks to authenticate again (should it?), and it caches the keyphrase again.

Revision history for this message
Felipe Figueiredo (philsf) wrote :

There's no command line option to pass a directory to g-k-d in runtime. I'll open a wishlist bug to be triaged for this.

Chow Loong Jin (hyperair)
Changed in gnome-keyring:
status: New → Confirmed
Revision history for this message
In , Julian (julian-redhat-bugs) wrote :

Erm, it is still present with Fedora 10. After thorough testing, I found out that this bug is only triggered by hibernation, and that you don't have do to anything prior to it. Do I need to say it makes hibernation pretty much useless, since once you resume you need to input your keyring password every time? Imagine updating a package in cvs like that...

Revision history for this message
In , Matthias (matthias-redhat-bugs) wrote :

This is a somewhat confused bug report.

If you are talking about ssh, seahorse is not involved, gnome-keyring-daemon is acting as ssh agent.

Revision history for this message
In , Julian (julian-redhat-bugs) wrote :

$ gnome-keyring-daemon
** Message: another SSH agent is running at: /tmp/keyring-XZf6Tg/ssh
GNOME_KEYRING_SOCKET=/tmp/keyring-SR9ZYj/socket
SSH_AUTH_SOCK=/tmp/keyring-SR9ZYj/ssh
GNOME_KEYRING_PID=17745

This is what happens if I try to start gnome-keyring-daemon manually after waking up from hibernation.

Revision history for this message
In , Julian (julian-redhat-bugs) wrote :

On the other hand, gnome-keyring-daemon does not show up in the list of running processes.

Revision history for this message
Sean Hodges (seanhodges) wrote :

Work-around works great for me, thanks Felipe.

Possibly related bug: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/220165. Suggests adjusting the gnome_keyring_hibernate setting in gconf-editor.

Related bug at Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=454186

Upstream bug (new): http://bugzilla.gnome.org/show_bug.cgi?id=569253

Revision history for this message
Tim Starling (tstarling) wrote :

I reproduced this issue on Intrepid by starting gnome-keyring-daemon in the foreground and then sending the computer into hibernate:

tstarling@shimmer:~$ killall gnome-keyring-daemon
tstarling@shimmer:~$ gnome-keyring-daemon -f
** Message: another SSH agent is running at: /tmp/keyring-3pQJ5l/ssh
GNOME_KEYRING_SOCKET=/tmp/keyring-idImLe/socket
SSH_AUTH_SOCK=/tmp/keyring-idImLe/ssh
GNOME_KEYRING_PID=21817
**
ERROR:gkr-keyring.c:504:gkr_keyring_lock: assertion failed: (keyring->password != NULL)
Aborted
tstarling@shimmer:~$

The assertion occurred shortly after I clicked "hibernate", I saw it in the terminal before the screen went off.

Sebastien Bacher (seb128)
Changed in gnome-keyring:
assignee: nobody → desktop-bugs
status: Confirmed → Triaged
milestone: none → ubuntu-9.04-beta
Revision history for this message
Chow Loong Jin (hyperair) wrote : Re: [Bug 268141] Re: no ssh-agent after resume from hibernate

On Mon, 2009-01-26 at 22:01 +0000, Sean Hodges wrote:
> Work-around works great for me, thanks Felipe.
>
> Possibly related bug: https://bugs.launchpad.net/ubuntu/+source/gnome-
> keyring/+bug/220165. Suggests adjusting the gnome_keyring_hibernate
> setting in gconf-editor.
>
> Related bug at Redhat:
> https://bugzilla.redhat.com/show_bug.cgi?id=454186
>
> Upstream bug (new): http://bugzilla.gnome.org/show_bug.cgi?id=569253
>
 I noticed that the bug seems to occur while suspending and not
hibernating. Also, when I checked gconf-editor, it would seem as though
gnome_keyring_hibernate was set to true, whereas gnome_keyring_suspend
was set to false. Perhaps GPM locking the kerying before hibernating is
causing the said bug? I'll test with gnome_keyring_hibernate set to
false for a while.
--
Chow Loong Jin

Bug Watch Updater (bug-watch-updater)
Changed in gnome-keyring:
status: Unknown → New
Revision history for this message
Chow Loong Jin (hyperair) wrote :

Alright, I can confirm that adjusting the gnome_keyring_hibernate
setting to false (unchecked) seems to solve the said issue. My gnome
keyring doesn't crash any more upon hibernation.
--
Chow Loong Jin

Revision history for this message
Felipe Figueiredo (philsf) wrote :

I can confirm that hyperair's workaround works, and it's better, since it requires no user intervention, and it's easier for newbies.

I still believe that this is a bug, not a feature, since there appears to be no obvious way to restart the g-k-m after a hibernation/suspend, if the mentioned options are active. I also agree that, for security reasons, the gnome_keyring_hibernate shouldn't come deactivated, because of bug #70752. However, it seems to me that solving bug #70752 by encrypting swap would make hibernation impossible.

Bug Watch Updater (bug-watch-updater)
Changed in gnome-keyring:
status: Unknown → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in gnome-keyring:
status: New → Fix Released
Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Sat, 2009-01-31 at 05:24 +0000, Bug Watch Updater wrote:
> ** Changed in: gnome-keyring
> Status: New => Fix Released
>
 Well, it seems upstream fixed the issue in trunk. So we just have to
wait for the next release of gnome-keyring, and it should be fixed
there.
--
Chow Loong Jin

Revision history for this message
Felipe Figueiredo (philsf) wrote :

On Sat, Jan 31, 2009 at 6:07 AM, hyperair <email address hidden> wrote:
> On Sat, 2009-01-31 at 05:24 +0000, Bug Watch Updater wrote:
>> ** Changed in: gnome-keyring
>> Status: New => Fix Released
>>
> Well, it seems upstream fixed the issue in trunk. So we just have to
> wait for the next release of gnome-keyring, and it should be fixed
> there.

Or someone who has the proper skills gets the patch for that revision,
and tries to use it in ubuntu's version. Maybe then, we can start a
SRU process, if it's applicable. Volunteers?

Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Sat, 2009-01-31 at 18:46 +0000, Felipe Figueiredo wrote:
> On Sat, Jan 31, 2009 at 6:07 AM, hyperair <email address hidden> wrote:
> > On Sat, 2009-01-31 at 05:24 +0000, Bug Watch Updater wrote:
> >> ** Changed in: gnome-keyring
> >> Status: New => Fix Released
> >>
> > Well, it seems upstream fixed the issue in trunk. So we just have to
> > wait for the next release of gnome-keyring, and it should be fixed
> > there.
>
> Or someone who has the proper skills gets the patch for that revision,
> and tries to use it in ubuntu's version. Maybe then, we can start a
> SRU process, if it's applicable. Volunteers?
>
 Alright, here's a debdiff for Intrepid. It still needs to be fixed in
Jaunty though, and needs to be approved for Intrepid.
--
Chow Loong Jin

Revision history for this message
Chow Loong Jin (hyperair) wrote :

Okay, it seems that the previous debdiff had a typo in it so it FTBFS'd.
Attached is one which shouldn't FTBFS.
--
Chow Loong Jin

Revision history for this message
Chow Loong Jin (hyperair) wrote :

..looks like I messed up the previous patch as well. Here's one that's
tested (I finally had the sense to test it before uploading).
--
Chow Loong Jin

Chow Loong Jin (hyperair)
description: updated
description: updated
Revision history for this message
Chow Loong Jin (hyperair) wrote :

And here's a debdiff for Jaunty's gnome-keyring.
--
Chow Loong Jin

Chow Loong Jin (hyperair)
Changed in gnome-keyring:
assignee: desktop-bugs → hyperair
Revision history for this message
Christophe Sauthier (christophe.sauthier) wrote :

Thanks for your work here. The thing is that there is already a new gnome-keyring version available (2.25.5.) which FTBFS for the moment on jaunty. I am currently working with upstream to fix that. I'll integrate your work in the next package for jaunty (this week I think).

Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Sun, 2009-02-01 at 17:42 +0000, Christophe Sauthier (huats) wrote:
> Thanks for your work here. The thing is that there is already a new
> gnome-keyring version available (2.25.5.) which FTBFS for the moment on
> jaunty. I am currently working with upstream to fix that. I'll integrate
> your work in the next package for jaunty (this week I think).
>
 Okay, awesome. How about SRU for Intrepid after that?
--
Chow Loong Jin

Revision history for this message
Felipe Figueiredo (philsf) wrote :

On Sun, Feb 1, 2009 at 3:51 PM, hyperair <email address hidden> wrote:
> On Sun, 2009-02-01 at 17:42 +0000, Christophe Sauthier (huats) wrote:
>> Thanks for your work here. The thing is that there is already a new
>> gnome-keyring version available (2.25.5.) which FTBFS for the moment on
>> jaunty. I am currently working with upstream to fix that. I'll integrate
>> your work in the next package for jaunty (this week I think).
>>
> Okay, awesome. How about SRU for Intrepid after that?
> --

And Hardy also.

Thanks hyperair.

Revision history for this message
Chow Loong Jin (hyperair) wrote :

On Sun, 2009-02-01 at 19:09 +0000, Felipe Figueiredo wrote:
> On Sun, Feb 1, 2009 at 3:51 PM, hyperair <email address hidden> wrote:
> > On Sun, 2009-02-01 at 17:42 +0000, Christophe Sauthier (huats) wrote:
> >> Thanks for your work here. The thing is that there is already a new
> >> gnome-keyring version available (2.25.5.) which FTBFS for the moment on
> >> jaunty. I am currently working with upstream to fix that. I'll integrate
> >> your work in the next package for jaunty (this week I think).
> >>
> > Okay, awesome. How about SRU for Intrepid after that?
> > --
>
> And Hardy also.
>
> Thanks hyperair.
>
 You're welcome and here's a Hardy debdiff.
--
Chow Loong Jin

Revision history for this message
In , Ian (ian-redhat-bugs) wrote :

Possibly related to this - gnome-keyring-daemon *sometimes* dies if left running overnight. For example yesterday afternoon I had this:

   > set | grep SSH
   SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
   SSH_AUTH_SOCK=/tmp/keyring-y0Zso0/ssh

   > fuser $SSH_AUTH_SOCK
     2674
   > ps h `fuser $SSH_AUTH_SOCK`
    2674 ? S 0:37 /usr/bin/gnome-keyring-daemon -d --login

All working nicely. This morning I got:

   > set | grep SSH
   SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass
   SSH_AUTH_SOCK=/tmp/keyring-y0Zso0/ssh

   > fuser $SSH_AUTH_SOCK

which means the gnome-keyring-daemon process has died.

It seems like the process dies (or is killed) when the screensaver is unlocked in the morning rather than during the night. (screensaver unlock doesn't always do that though).

--
Ian

Revision history for this message
Sebastien Bacher (seb128) wrote :

the new version is in jaunty now

Changed in gnome-keyring:
status: Triaged → Fix Released
assignee: hyperair → nobody
Revision history for this message
In , Julian (julian-redhat-bugs) wrote :

I checked with gdb and got the following:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7f68bc4f4950 (LWP 5401)]
0x00000032b3432f05 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) bt
#0 0x00000032b3432f05 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00000032b3434a73 in abort () at abort.c:88
#2 0x0000003c6925d803 in IA__g_assertion_message (domain=0x3c692b72fe "",
    file=0x453b0b "gkr-keyring.c", line=<value optimized out>,
    func=0x453cd0 "gkr_keyring_lock", message=<value optimized out>)
    at gtestutils.c:1301
#3 0x0000003c6925dca2 in IA__g_assertion_message_expr (domain=0x0,
    file=0x453b0b "gkr-keyring.c", line=504, func=0x453cd0 "gkr_keyring_lock",
    expr=<value optimized out>) at gtestutils.c:1312
#4 0x000000000043eac9 in gkr_keyring_lock (keyring=0x13715f0)
    at gkr-keyring.c:504
#5 0x000000000040bdf9 in lock_each_keyring (keyring=0x14ff, unused=0x1519)
    at gkr-daemon-ops.c:722
#6 0x0000000000442a59 in gkr_keyrings_foreach (
    func=0x40bdf0 <lock_each_keyring>, data=0x0) at gkr-keyrings.c:389
#7 0x000000000040da20 in op_lock_all (packet=<value optimized out>,
    result=0x136a440, req=0x6) at gkr-daemon-ops.c:730
#8 0x000000000040b93a in client_worker_main (user_data=<value optimized out>)
    at gkr-daemon-io.c:298
#9 0x0000000000430aba in async_worker_thread (data=<value optimized out>)
    at gkr-async.c:269
#10 0x0000003c69260d44 in g_thread_create_proxy (data=0x136e0b0)
---Type <return> to continue, or q <return> to quit---
    at gthread.c:635
#11 0x00000032b40073da in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#12 0x00000032b34e62bd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
(gdb) c
Continuing.
[Thread 0x7f68bc4f4950 (LWP 5401) exited]

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.

I'm not sure how useful it is, though.

Revision history for this message
In , Ian (ian-redhat-bugs) wrote :

I've found that the keyring-daemon dies unpredictably. I've had it die a few minutes after login but mostly after longer periods. Sometimes it will run for days before dying and on rare occasions gets through an entire working week without a failure.

Revision history for this message
In , Julian (julian-redhat-bugs) wrote :

Looks like it finally works in Fedora 11.

Bug Watch Updater (bug-watch-updater)
Changed in gnome-keyring (Fedora):
status: Confirmed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in gnome-keyring:
importance: Unknown → Critical
Bug Watch Updater (bug-watch-updater)
Changed in gnome-keyring (Fedora):
importance: Unknown → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.