Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 458694 - gnome-ssh-askpass no longer works
Summary: gnome-ssh-askpass no longer works
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-keyring
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tomáš Bžatek
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F10Blocker, F10FinalBlocker F10DesktopBlocker
TreeView+ depends on / blocked
Reported: 2008-08-11 16:52 UTC by Adam Jackson
Modified: 2018-04-11 08:50 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-08-26 18:05:14 UTC
Type: ---

Attachments (Terms of Use)
Xsession patch (393 bytes, patch)
2008-08-24 05:25 UTC, Matthias Clasen
no flags Details | Diff

Description Adam Jackson 2008-08-11 16:52:54 UTC
Description of problem:

aspartame:~% echo $SSH_ASKPASS      
aspartame:~% echo $DISPLAY
aspartame:~% ssh -fN git.fedorahosted.org
Enter passphrase for key '/home/ajax/.ssh/id_dsa': 

I'd expect to see a gtk dialog.  Even better, to not see one, since the keyring should already be unlocked.

ssh -v doesn't say anything enlightening.

Version-Release number of selected component (if applicable):

aspartame:~% rpm -qf /usr/libexec/openssh/gnome-ssh-askpass

Comment 1 Tomas Mraz 2008-08-11 17:06:07 UTC
Could it be that the gnome-keyring is taking over the ssh-agent functionality?


Comment 2 Bastien Nocera 2008-08-12 22:08:49 UTC
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.

Comment 3 Tomas Mraz 2008-08-13 17:20:07 UTC
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.

Comment 4 Adam Jackson 2008-08-15 16:26:35 UTC
That lsof command prints nothing.

Comment 5 Matthias Clasen 2008-08-24 02:50:54 UTC
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.

Comment 6 Matthias Clasen 2008-08-24 04:37:36 UTC
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"

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.

Comment 7 Matthias Clasen 2008-08-24 04:54:41 UTC
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

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.

Comment 8 Matthias Clasen 2008-08-24 05:20:05 UTC
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.

Comment 9 Matthias Clasen 2008-08-24 05:25:50 UTC
Created attachment 314873 [details]
Xsession patch

Comment 10 Ray Strode [halfline] 2008-08-25 13:36:52 UTC
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.

Comment 11 Steven W. Carter 2009-06-11 13:15:38 UTC
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.

Comment 12 Matěj Cepl 2009-11-05 17:12:02 UTC
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.]

Comment 13 Bug Zapper 2009-11-16 08:11:14 UTC
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:

Comment 14 Matěj Cepl 2010-02-26 12:26:50 UTC
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]

Comment 15 Steven W. Carter 2010-02-26 14:23:15 UTC
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".

Comment 17 Steven W. Carter 2010-04-23 21:55:12 UTC
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.

Comment 18 Adam Jackson 2010-08-26 18:05:14 UTC
I haven't seen this in F13 or F14.

Note You need to log in before you can comment on or make changes to this bug.