After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 627815 - gnome-keyring ssh agent doesn't unlock ssh keys anymore
gnome-keyring ssh agent doesn't unlock ssh keys anymore
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: general
2.31.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-08-24 08:45 UTC by Götz Waschk
Modified: 2010-12-04 18:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Götz Waschk 2010-08-24 08:45:39 UTC
This is on Mandriva Cooker with gnome-keyring 2.31.4. Since the upgrade to gnome 2.31, the
gnome-keyring ssh agent doesn't unlock ssh keys anymore at session start.

ssh-add -l shows the key loaded in memory, but any attempt to use them trigger
a pop-up windows asking for the passphrase. Which is likely to be used by ssh
directly, and not by the agent, as any subsequent use of the key trigger the
pop-up windows again.

[guillaume@beria Bureau]$ ssh-add -l
2048 2c:79:ca:d4:c4:41:f9:06:e6:54:6a:1c:3b:59:05:13 mandriva (RSA)
...
[guillaume@beria Bureau]$ ssh n2.mandriva.com
-> pop-up windows

The seahorse keyring looks OK, as my login keyring is automatically unlocked.

The only thing that works around this is to call ssh-add from the shell manually and then enter the passphrase.
Comment 1 Stef Walter 2010-09-01 03:02:21 UTC
Thanks for bringing that up. I believe this should fix the problem. Internally gnome-keyring was ignoring the login keyring for looking up unlocking secrets because of a bad flag.

commit d9ef94455d115d8fed29a3071b5b19ca632fb932
Author: Stef Walter <stef@memberwebs.com>
Date:   Wed Sep 1 02:59:13 2010 +0000

    [secret-store] Fix the CKA_TRUSTED attribute for collections.
    
    This attribute signifies whether the collection is properly encrypted
    or not. Fix broken boolean check.


Please reopen if this doesn't fix your problem.
Comment 2 Tobias Wolf 2010-09-10 21:05:25 UTC
I patched 2.31.91 with your commit and there was no change. It’s still asking me to unlock the key.

Do I need more from git besides this?
Comment 3 Tobias Wolf 2010-09-10 21:06:47 UTC
BTW, here I only need to type the passphrase once into the gnome-keyring window. After that, further uses of the SSH key go through.
Comment 4 Milan Bouchet-Valat 2010-10-12 19:24:06 UTC
Reopening, because several users in Ubuntu support the conclusion from the above comment. Feel free to close again if you think that's not related, but else, just ask the information you need to debug!
Comment 5 Liam O'Reilly 2010-10-13 08:38:29 UTC
I have this same issue.

I have many things stored in my login keyring (viewed by opening "Passwords and Encryption Keys" and looking at the "Passwords" Tab. The things included in my login keyring are:
-> Network secretes
-> Desktop Couch user authentication - Used by Ubuntu One
-> Empathy and Gwibber passwords
However there is no entry for pass-phrases for SSH keys in here.

In the "My Personal Keys" tab there is an entry for my SSH key. As I understand it, this is the key itself and the unlock pass-phrase for this key should be stored in the login keyring, but (as I just said) it is not.

I am sure the login keyring used to contain a pass-phrase entry on the previous version of Ubuntu. In the previous Ubuntu, the first time I used SSH, a popup would open asking for the pass-phrase and once I entered the data, the pass-phrase would be stored in the login key ring.

Now when I use SSH, I get a popup "Unlock private key" asking "Enter password to unlock the private key. An application wants to access the private key x@x but it is locked." There are the following options under "Details"
-> Lock this keyring when I logout.
-> Lock this keyring after x minutes.
-> Lock this keyring if idle for x minutes.

After entering the pass-phrase and chooseing any of these options, the pass-pharse is not stored in the login keyring.

Also the login keyring must be unlocked as my network connections on login, after only entering my login at the Gnome login screen. So the login keyring is being unlocked successfully, but the SSH pass-phrase is not being stored inside it in the first place.

I am running Ubuntu 10.10 64 bit with the Gnome-keyring package 2.92.92.is.2.32.91-0ubuntu4.
Comment 6 rexnoorm 2010-10-21 17:42:00 UTC
Exactly the same to me.
I installed Ubuntu 10.10 32 bit. Network and Empathy keys are stored in Gnome-Keyring but the key to unlock my private SSH key not. The first time you use the SSH key, in former Ubuntu versions, you could choice in the appearing pop-up windows a selection for storing the SSH key. Different from the actual Ubuntu version. There are only the 3 already mentioned options.

Replacing the folder ~/.gnome2/keyrings with the one I used in Ubuntu 10.04 following with log-off and log-in worked for me.
Comment 7 Chris Green 2010-10-24 12:50:50 UTC
I have something similar to these problems too.  I'm running xubuntu 10.04.

What I have done to get things to work properly is to add the following to my .xprofile :-

    eval $(gnome-keyring-daemon --start)
    export SSH_AUTH_SOCK
    export GNOME_KEYRING_SOCKET

I realise that this isn't a proper fix but it might point someone to what the problem is.
Comment 8 Stef Walter 2010-10-25 21:59:10 UTC
What I'm interested in is a description of entries you have in your login keyring. 

In particular for any item that refers to your SSH key, I need a listing of the attributes. You can check this out via seahorse. Go into the properties of the item and click on the 'Details' tab.

Putting that information in this bug report shouldn't constitute a security problem for you. But if you're worried, you can email it to me directly.
Comment 9 Tobias Wolf 2010-10-25 22:43:24 UTC
Myself, I’m not sure what you are referring to.

In the list of passwords under the login keyring (the first tab in Seahorse) there is no entry that refers to my SSH key. Should there be one?

In the second tab (My Personal Keys) it lists my SSH key with the regular details:

Algo: DSA
Strength: 2048
Location: ~/.ssh/id_dsa
Fingerprint: xx:xx:...

Can you clarify?
Comment 10 Stef Walter 2010-10-25 22:55:58 UTC
Sorry, no I meant a password (in the login keyring, on the Passwords tab) that refers to the name of your SSH key. The item will be called something like "Unlock password for: xxx"
Comment 11 Tobias Wolf 2010-10-26 00:56:51 UTC
No, there’s nothing there.

BTW, this is the changelog of the last upload of gnome-keyring that I got.
Did your fix need anything newer than 2.32.91 besides this one commit?


gnome-keyring (2.92.92.is.2.31.91-0ubuntu4) maverick; urgency=low

  * 10_git_fix_cka_trusted_collections.patch: Add patch cherry-picked from
    upstream commit d9ef94455d115d8fed29a3071b5b19ca632fb932 to fix a
    broken boolean check. Fixes bug with keyring not being unlocked at
    session login. (LP: #631980)
    References: https://bugzilla.gnome.org/show_bug.cgi?id=627815

 -- Iain Lane <laney@ubuntu.com>  Thu, 30 Sep 2010 18:30:56 +0100
Comment 12 Tobias Wolf 2010-10-26 00:57:58 UTC
I’m sorry, newer than 2.31.91?
Comment 13 Stef Walter 2010-10-26 01:43:59 UTC
That's a very strange version. Both 2.32.0 and 2.32.1 have been released and are newer than 2.31.91.
Comment 14 Tobias Wolf 2010-10-26 02:08:53 UTC
I wish I could comment on that.
Comment 15 rexnoorm 2010-10-26 09:23:07 UTC
I have also no entry in the login keyring, on the Passwords tab. My gnome-keyring version is: 2.92.92.is.2.31.91-0ubuntu4
Comment 16 Tobias Wolf 2010-10-27 00:10:06 UTC
So I installed gnome-keyring from the 2.32.1 tarball without patches and it works as it should.

I don’t know why it wasn’t packaged when all ther other Gnome 2.32 modules are in 10.10.

Also, I like the g-k-d’s GPG agent better than the one from seahorse. But that one is still installed and used.
Comment 17 Stef Walter 2010-12-04 18:16:30 UTC
Okay closing if 2.32.1 fixes this. If not, please reopen...