Bug 442215

Hmm, I guess I have an id_dsa, just never use it. I've ssh-add'd a different key
called something else. 

I think "ssh-add ~/.ssh/somethingelse" definitely should not open an id_dsa
related dialog. I guess I can imagine that ssh to a server would need to, though
the server wants the somethingelse, not id_dsa

As for id_dsa, I'm guessing that when connecting to a remote server, ssh is
trying to access all the keys it can so that it can offer them.

Not ideal if the UI is "you must enter passphrase for all keys in order to use
any of them", though I have no idea how many people really have multiple keys.

(In reply to comment #0)
> Not sure which package this is coming from. Just upgraded to Rawhide. I am using
> ssh-agent.
> 
> When I do an "ssh", "ssh-add", "scp", or whatever, there is a GUI dialog with
> several problems. I guess I should split this bug up, but I'm lazy, and figure a
> lot of these are fixed already.
> 
> 1. I get a GUI dialog AND a text prompt from ssh-add. Should not do both, only
one.
I cannot reproduce this on freshly installed rawhide and on F8 with openssh
upgraded to 5.0p1 either. The GUI dialog should appear only when ssh-add doesn't
have tty as stdin and then there should be no text prompt of course.

> 2. The dialog does not make sense to me. I don't understand what the text means
> in it, or what it's asking for. Does it want my passphrase? gnome-keyring
> password? What is the "Location" and what does that have to do with anything?
> Why doesn't this dialog just say "enter your passphrase"?
The dialog prints just: "Enter passphrase for <path to the key>" or "Enter
passphrase for <name of the key if specified in the .pub file>" This seems to be
OK to me.

> 3. The dialog asks about 'id_dsa' as the key name, which I don't understand;
> that is not the filename of my private key. So not sure what this is the name of.
?? id_dsa is the default file name of the private key file in .ssh if it is a
DSA key.

> 4. The dialog is oddly almost-system-modal, in a way as the author of metacity
> I'm not even sure how one gets metacity to do (does it have a keygrab and not a
> mouse grab maybe? Not sure how the behavior happens, but it's definitely a bug).
> Basically I can click on other windows and they appear as focused, but they
> aren't really focused. So, this is just wrong. If the dialog should be modal, do
> a mouse grab too. But, it shouldn't be system modal.
We do a keyboard grab so a malicious application cannot steal the keystrokes.
Perhaps sane window managers now do not allow stealing keyboard focus without
user action so this grab could be disabled but I don't see it as big problem either.

> 5. The dialog appears even if the public key needed for the server I'm
> connecting to is already added to ssh-agent. If I click "deny" on the dialog
> then I'm just logged in. So what is the dialog about? There's no missing auth.
I don't understand - does it appear when you do simply ssh <user@host> on
terminal? I cannot reproduce this.

> 6. I don't understand what "Deny" means in this context. What am I denying? Does
> ssh-agent now work per-app instead of per-ssh-key? Is gnome-keyring taking over
> from ssh-agent? what is going on!
I'd like to know that too as I simply do not see this problem here.

> 7. ssh is a command line program, so I think it's a tad bit odd to open this
> dialog. Won't this dialog totally break my scripts that do "scp" and things of
> that nature? But even if it only happens if stdin is a tty, it's an odd break in
> workflow to be using a terminal and suddenly there's a dialog.
This would be surely a bug if ssh would open the dialog. Are you sure that you
don't have some weird alias in shell which would call ssh-add for you silently
before ssh invocation? Could you try to strace it?

I'm not sure we're looking at the same dialog. For me it does not contain the
word "passphrase" for example. I will attach a screenshot.

To answer some questions:
1. if I type ssh-add then I get a text prompt and the dialog. Note that I am
adding a different ssh key than the one the dialog asks about.

2. my dialog does not say "passphrase" or even "ssh" anywhere in it, and it has
"Location" of "Home" (which I guess means ~/.ssh)

3. you can have key files named anything, and multiple keys, though; e.g. some
people use different keys for different servers

4. the user interaction is clearly messed up, because you can click on other
windows and have them appear focused, but keystrokes still go to the dialog.
This is a bug in *something* - the UI is simply not correct. For system modal to
work, you would need clicks on other apps to do nothing and beep, for example.
(My opinion is that this is so hard to fix it's better to not grab.)

5. yes, if I ssh user@host in a terminal I get the dialog even though the
private key for that user@host is already ssh-added.

7.
$ type ssh
ssh is hashed (/usr/bin/ssh)

I can't figure out anything from the strace; it does not seem to fork or exec
anything??? so I don't see how it opens the dialog. "ssh -v" tells me nothing
either.

Created attachment 302352 [details]
screenshot of this dialog

I put a tail on the strace so I could see it while the dialog is up. It's
blocking on this socket while the dialog is up:
 connect(4, {sa_family=AF_FILE, path="/tmp/keyring-2SfBch/ssh"}, 110) = 0

Based on "strings gnome-keyring-daemon", the strings in this dialog are in that
daemon.

Hmmm this dialog definitely doesn't come from openssh. The gnome-ssh-askpass
dialog there is completely different.

How could the gnome-keyring mess up with ssh this way I don't know. Perhaps it
tries to replace ssh-agent?

Well, the dialog is still lengths better than the
type-in-a-single-character-entry abomination that is gnome-ssh-askpass.

Anyway, it does come from gnome-keyring, and it is a keep-above window with a
keyboard grab, but no mouse grab. Should probably grab both to make the
situation a bit less broken.

The location thing is about where a keyring is located when using this dialog
for keyrings. I agree that is it is a bit cryptic and has no place in the dialog
when it is used for ssh passphrases.

Filed upstream: http://bugzilla.gnome.org/show_bug.cgi?id=528122

The type-in-a-single-character-entry is not a single but at least 3 or 4 visible
character entry. Its purpose is to obscure the length of the entered passphrase
to onlookers. If gtk provided some other way how to obscure it I'd be very happy
to switch to that.

The ssh-agent/ssh-add provided by openssh at least doesn't ask you for
passphrases for keys which are already added to the agent. And it doesn't open
the dialog when you're running ssh/ssh-add on the terminal so it can ask for the
passphrase there.

If the gnome-keyring will now take over the role of ssh-agent in gnome would it
be at least possible to put the "gnome keyring" text in the dialog window
somewhere so people know against which package they should report the bugs?

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.