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 528122 - dialog for unlocking ssh keys is cryptic
dialog for unlocking ssh keys is cryptic
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: prompting
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2008-04-14 21:58 UTC by Matthias Clasen
Modified: 2009-02-23 02:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthias Clasen 2008-04-14 21:58:44 UTC
Havoc complains about this here:

https://bugzilla.redhat.com/show_bug.cgi?id=442215


The location stuff might make sense when dealing with keyrings which might be stored in different places, but for ssh keys, I don't see anything but confusion come from that... Also, as Havoc points out, if you grab the keyboard like that, you should also grab the mouse, otherwise the window management is pretty broken.
Comment 1 Havoc Pennington 2008-04-14 22:07:56 UTC
Most of the other stuff I'm reporting in the Red Hat bug looks like it's related to having two keys in ~/.ssh - that seems to result in showing the dialog when the needed key is already authorized. If I nuke the unused key, the dialog isn't popping up at inappropriate times anymore.

Re: the dialog wording, I would say the words "ssh" and "passphrase" really need to be included somehow.

Enter passphrase for ssh key '~/.ssh/id_dsa':
[                      ]
   [Cancel] [OK]

something like that. Short and sweet.

I realized the other thing bugging me - is this dialog about getting the passphrase, or about allow/deny a specific app from accessing the key? It sort of seems to be both at once. I think that may be the root of some confusion.
Comment 2 Matthias Clasen 2008-04-14 22:37:31 UTC
Hmm, I have two keys, and the dialog managed to pop up at the right times and ask about the right key, exactly once for each key...
Comment 3 Havoc Pennington 2008-04-14 22:44:28 UTC
So I did "ssh-add ~/.ssh/key1" and got a dialog about key2. (When neither had been previously added.)

Then, "ssh user@host" to a server expecting key1, which was already added, I got a dialog about key2 again.

I don't know the passphrase for the key2, so I've never typed it in. But basically when doing things related to key1, I am asked about key2.

Comment 4 Matthias Clasen 2008-04-15 02:26:06 UTC
Oh, I never do hitech things like ssh-add. I just type svn up or git pull and am happy if the dialog comes up and remembers my key for next time...
Comment 5 Stef Walter 2008-04-17 00:07:06 UTC
Whoops, the location stuff is only supposed to show up when you're doing fancy things. Fixed in gnome-2-22:

	* common/gkr-location.h:
	* ui/gkr-ask-request.c: Don't show 'Location' in password prompt 
	for objects in the user's home directory.

Fixed that, will look into some of the other stuff. 
Comment 6 Stef Walter 2008-04-17 00:21:13 UTC
Here's where the problem and confusion lies:

The first time gnome-keyring accesses your SSH (or other) keys it tries to import them so it knows how to handle them. The dialog that comes up has the following text:

   The system wants to import the private key '%s', but it is locked

gnome-keyring does this so it can gather information about the key, and then use that later to do challenge response with servers, etc...

A bug: Even if you click 'Deny' then gnome-keyring thinks its been imported, and things go awry with undescriptive messages etc...

Comment 7 Stef Walter 2008-04-18 21:06:53 UTC
Fixed most of the irritations:

2008-04-18  Stef Walter  <stef@memberwebs.com>

	* pk/gkr-pk-index.c:
	* pk/gkr-pk-index.h:
	* pk/gkr-pk-object.c:
	* pk/gkr-pk-object.h:
	* pk/gkr-pk-object-storage.c:
	* pk/gkr-pk-privkey.c: 
	* ui/gkr-ask-request.h: Streamline the importing of keys, and make 
	the proper 'import' prompt come up when importing. Don't repeatedly
	try to import a key that a user doesn't want to import. Use the 'cancel'
	label instead of 'deny' for the import prompt. See bug #528122

The dialogs for this will get more work during the 2.24 cycle, so I won't close the bug. 
Comment 8 Matthias Clasen 2009-02-23 02:49:49 UTC
I consider this fixed in current gnome-keyring