Bug 458694

Summary: gnome-ssh-askpass no longer works
Product: [Fedora] Fedora Reporter: Adam Jackson <ajax>
Component: gnome-keyringAssignee: Tomáš Bžatek <tbzatek>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 12CC: dcantrell, internetbummer, mcepl, mcepl, mclasen, poelstra, rstrode, tbzatek, tsmetana, walters
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-26 14:05:14 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 438943, 457945    
Description Flags
Xsession patch none

Description Adam Jackson 2008-08-11 12:52:54 EDT
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 13:06:07 EDT
Could it be that the gnome-keyring is taking over the ssh-agent functionality?

Comment 2 Bastien Nocera 2008-08-12 18:08:49 EDT
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 13:20:07 EDT
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 12:26:35 EDT
That lsof command prints nothing.
Comment 5 Matthias Clasen 2008-08-23 22:50:54 EDT
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 00:37:36 EDT
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 00:54:41 EDT
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 01:20:05 EDT
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 01:25:50 EDT
Created attachment 314873 [details]
Xsession patch
Comment 10 Ray Strode [halfline] 2008-08-25 09:36:52 EDT
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 09:15:38 EDT
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 12:12:02 EST
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 03:11:14 EST
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 07:26:50 EST
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 09:23:15 EST
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 17:55:12 EDT
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 14:05:14 EDT
I haven't seen this in F13 or F14.