GNOME Bugzilla – Bug 519486
Starts ssh component even when a ssh-agent is running and tells gnome-session to overwrite the env vars
Last modified: 2008-04-06 15:54:55 UTC
Hi, as triggerred and described in bug #503278, gnome-keyring will now hide the ssh-agent I want to use. A workaround is to disable the ssh component in the g-k GConf config, but I think gnome-keyring shouldn't start the ssh component if another ssh-agent is already running. (This could perhaps still be forced by matters of --force or a new force_startup GConf key, but please don't hide the running agents by default.) Thanks,
Good point. This is a bit involved due to all the locations that start gnome-keyring-daemon (the PAM module for example could start it long before any other process in the session). It may be easy to fix, but it needs some thought to be correct. Seems there are some trade offs either way. It may be rather confusing if the user/admin chose the gconf key for enabling the ssh component, but then it didn't work that way, due to gnome-keyring allowing another agent's ssh-agent variables to be present even though the ssh component in the gnome-keyring daemon has started.
This is biting more and more people, e.g. from Planet Debian: http://www.netfort.gr.jp/~dancer/diary/daily/2008-Apr-1.html.en#2008-Apr-1-07:53:56 from the Debian BTS: http://bugs.debian.org/473864 and I told at least 2 people on IRC how to workaround this. First, I think the bug would affect less people the other way around (I think less people would be bothered by gnome-keyring not starting the ssh component when a running agent is detected). Second, I really feel the running agent is the one that should be honored; you can log something in .xsession-errors if you detect it if it you think users should know about it. I don't think we want to add configuration for things like "force starting ssh component if ssh agent detected": this would pollute GConf for each use case of anything which could go wrong and would basically encode logic into GConf booleans.
I believe it would affect more people the other way around. Besides the typical example of non-power users who expect the GConf setting to work... another example: there may be reasons for running distinct SSH agents, depending on whether a GUI session is being used or not. I've added a configure option --disable-ssh-agent and a warning that displays when another SSH agent is detected. I believe that should be good enough for: a) Distros to choose an appropriate default for their users. b) Advanced users who can see the status at the end of the ./configure output. And then there's also the gconf option for those who want to change the behavior of an already built gnome-keyring.
Well the request was to not start the ssh component *if* an already running ssh-agent already runs. This doesn't really help distros as we now have to chose whether we listen to users who use ssh-agent already or users who want an agent for SSH provided by gnome-keyring... IOW, only runtime tweaks can help, or (GConf) settings. But again, I don't see why someone would be advanced enough to want different SSH agents in GUI and non-GUI, yet wouldn't be advanced enough to hide the non-GUI agent in GUI sessions or to force the GUI agent in GUI sessions? What about: i) these users using env -i/-u to hide their non-GUI ssh-agent when running the GUI or ii) a --replace flag (or --force) to force gnome-keyring to start the ssh component when an already running ssh agent is present? (Much like the window manager.)