Could it be that the gnome-keyring is taking over the ssh-agent functionality?

lsof $SSH_AUTH_SOCK ?

The gnome-keyring nicely gets me a dialogue allowing me to unlock my ssh key without any need for any kind of setup, or using gnome-ssh-askpass.

Sorry, but this is not triaged yet. For example we still don't know whether the gnome-keyring is in charge of the keys at ajax's machine (instead of the regular ssh-agent) or not. If yes, then this bug should be reassigned to gnome-keyring as openssh cannot fix it.

That lsof command prints nothing.

For me sudo lsof $SSH_AUTH_SOCK shows that ssh-agent in fact owns that socked.
SSH_AGENT_PID is the pid of ssh-agent, and SSH_ASKPASS is /usr/libexec/openssh/gnome-ssh-askpass.

Still, ssh just prompts in the terminal, not by opening a dialog.

It is currently not quite clear to me how gnome-keyring and/or seahorse are supposed to take over the gnome-ssh-askpass functionality. seahorse-plugin ships a seahorse-agent, but that only sets GPG envvars, nothing related to ssh.

Ok, I've figured out what is happening on the gnome-keyring side here.

gnome-keyring-daemon still has the ssh-askpass functionality, but it doesn't work in rawhide, since g-k-d is now started insided the session, when ssh-agent is already running, due to this section in xinitrc-common:

if [ -x /usr/bin/ssh-agent -a -z "$SSH_AGENT_PID" ]; then
    if [ "x$TMPDIR" != "x" ]; then
        SSH_AGENT="/usr/bin/ssh-agent /bin/env TMPDIR=$TMPDIR"
    else
        SSH_AGENT="/usr/bin/ssh-agent"
  fi
fi

As a simple workaround, I have put a simple script in /etc/X11/xinitrc.d
that just does an

export SSH_AGENT_PID=unknown

and, voila, gnome-keyring-daemon prompts for and remembers ssh passphrases.

While probably not ideal, adding a script like

if [ -x /usr/bin/gnome-keyring-daemon ]; then
  gkr_ssh_enabled=`gconftool-2 --get /apps/gnome-keyring/daemon-components/ssh 2>/dev/null`
  if [ "$gkr_ssh_enabled" = "true" ]; then
    export SSH_AGENT_PID=unknown
  fi
fi

in /etc/X11/xinit/xinitrc.d would allow users to switch between ssh-agent 
and gnome-keyring-daemon's ssh-agent functionality by setting the GConf
key /apps/gnome-keyring/daemon-components/ssh.

Instead of misusing SSH_AGENT_PID, we should probably introduce a variable with the explicit purpose of controlling the launching of ssh-agent.

On the flip side, after trying to get through the shell script mess that is our X startup scripts, it seems to me that we already removed $SSH_AGENT from the gnome case in /etc/X11/xinit/Xsession (see bug 441123) and we only run into this problem because gdm calls "Xsession gnome-session" nowadays, not "Xsession gnome", so we run into the fallback case of the the switch in the Xsession script.

So an alternative fix would be to change gnome) to gnome-session).

CCing Ray for his opinion.

Created attachment 314873 [details]
Xsession patch

If you're using SSH_ASKPASS=/usr/libexec/openssh/gnome-ssh-askpass then you get the dialog by doing something like

ssh-add < /dev/null

That's the non-gnome-keyring dialog.

attachment 314873 [details] is okay, and will fix the gnome-keyring passphrase dialog currently.  It will break though, if we ever get pam-gnome-keyring working again.

ssh-add < /dev/null isn't really an acceptable solution.  While that worked, and brought up the graphical passphrase entry dialog for inclusion into the keyring, the idea is that it should "just work" as it once did.  I remember being surprised by the new feature when I attempted to ssh to a machine and it asked for my passphrase and then remembered it in the keyring.  How will new gnome users learn about this "ssh-add < /dev/null"?  It took 45 minutes of googling last night and finally coming across this post to make something work that *used* to work.  This didn't work for me on the F11 preview release fully updated to rawhide, and now it doesn't work in the fully updated F11 final release.

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]

The current upgraded system does not work.  The workaround that I've found is to add "ssh-add" to "System->Preferences->Startup Applications" list.  The gnome passphrase entry window then comes up instead of prompting for the passphrase in the terminal and the passphrase is stored in the keyring.

This is contrary to the previous behavior where the passphrase entry and keyring storage "just worked".

While my workaround (adding ssh-add to the startup applications in gnome) this should be added by default to enable ease of use for other users.

I haven't seen this in F13 or F14.