After I've used ssh on a connection with RSA authorization and given my keyring's passphrase to gnome-ssh-askpass, that keyring is now unlocked and future connections can be made without the passphrase. Is there a way, short of logging out and back in, to make the passphrase required again for a connection? I'd rather not have to uninstall or disable openssh-askpass since it's nice not to have to supply a lengthy passphrase repeatedly when needed in a short period, but I really don't like leaving that key open indefinitely.
In searching for info I keep getting references to ssh-agent being responsible for remembering the key, but I find that ssh-agent is never executed on my system.
I'm running currently updated Fedora 10 with Gnome.
On 03Mar2009 01:06, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
After I've used ssh on a connection with RSA authorization and given my keyring's passphrase to gnome-ssh-askpass, that keyring is now unlocked and future connections can be made without the passphrase. Is there a way, short of logging out and back in, to make the passphrase required again for a connection? I'd rather not have to uninstall or disable openssh-askpass since it's nice not to have to supply a lengthy passphrase repeatedly when needed in a short period, but I really don't like leaving that key open indefinitely.
In searching for info I keep getting references to ssh-agent being responsible for remembering the key, but I find that ssh-agent is never executed on my system.
I wonder how you find that, since it _is_ ssh-agent which provides this service. What specific checks have you made?
Go:
env | grep '^SSH'
Is there an SSH_AUTH_SOCK?
Find the ssh and kill it. Or modify your envionment sufficiently to gain control over the ssh-agent (or simply start your own). By using the -t option to ssh-agent when you start it you can control how long an added key starts "good". You can also add a key with ssh-add and specify a timeout then.
Cheers,
Robert Nichols wrote:
In searching for info I keep getting references to ssh-agent being responsible for remembering the key, but I find that ssh-agent is never executed on my system.
Here's one way to do it - the brute force solution.
Look under
Applications -> Internet -> SSH Ask Pass
then right click and add it to your panel.
Then right click on the icon in the panel, select properties, then change the command
/usr/bin/ssh-add
to
/usr/bin/ssh-add -t <time>
Cameron Simpson wrote:
On 03Mar2009 01:06, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
After I've used ssh on a connection with RSA authorization and given my keyring's passphrase to gnome-ssh-askpass, that keyring is now unlocked and future connections can be made without the passphrase. Is there a way, short of logging out and back in, to make the passphrase required again for a connection?
[SNIP]
In searching for info I keep getting references to ssh-agent being responsible for remembering the key, but I find that ssh-agent is never executed on my system.
I wonder how you find that, since it _is_ ssh-agent which provides this service. What specific checks have you made?
I renamed /usr/bin/ssh-agent to /usr/bin/xxx-agent and rebooted. Everything worked just as before. That file has no other hard links.
Go:
env | grep '^SSH'
Is there an SSH_AUTH_SOCK?
Find the ssh and kill it. Or modify your envionment sufficiently to gain control over the ssh-agent (or simply start your own). By using the -t option to ssh-agent when you start it you can control how long an added key starts "good". You can also add a key with ssh-add and specify a timeout then.
The process at the other end of $SSH_AUTH_SOCK is "gnome-keyring-daemon -d -login". That process gets created when I log in. Killing it doesn't strike me as a good idea. Indeed, other keyring related stuff breaks if I do that.
Agile Aspect wrote:
Robert Nichols wrote:
In searching for info I keep getting references to ssh-agent being responsible for remembering the key, but I find that ssh-agent is never executed on my system.
Here's one way to do it - the brute force solution.
Look under
Applications -> Internet -> SSH Ask Pass
then right click and add it to your panel.
Then right click on the icon in the panel, select properties, then change the command
/usr/bin/ssh-add
to
/usr/bin/ssh-add -t <time>
I do not find any "SSH Ask Pass" under Applications -> Internet. This is on a pretty much default install of Fedora 10. What are you running?
When I execute ssh-add in a terminal session, I get
$ /usr/bin/ssh-add -t 60 Enter passphrase for /home/rnichols/.ssh/id_rsa: [I enter the correct passphrase here] SSH_AGENT_FAILURE Identity added: /home/rnichols/.ssh/id_rsa (/home/rnichols/.ssh/id_rsa)
Thereafter, ssh happily without requiring a passphrase, and that capability does _not_ time out.
Thanks for the effort, but that doesn't help at all.
On Tue, Mar 03, 2009 at 09:18:46AM -0600, Robert Nichols wrote:
Cameron Simpson wrote:
Go:
env | grep '^SSH'
Is there an SSH_AUTH_SOCK?
Find the ssh and kill it. Or modify your envionment sufficiently to gain control over the ssh-agent (or simply start your own). By using the -t option to ssh-agent when you start it you can control how long an added key starts "good". You can also add a key with ssh-add and specify a timeout then.
The process at the other end of $SSH_AUTH_SOCK is "gnome-keyring-daemon -d -login". That process gets created when I log in. Killing it doesn't strike me as a good idea. Indeed, other keyring related stuff breaks if I do that.
Does this page help you at all? http://live.gnome.org/GnomeKeyring/Ssh
Robert Nichols wrote:
The process at the other end of $SSH_AUTH_SOCK is "gnome-keyring-daemon -d -login". That process gets created when I log in. Killing it doesn't strike me as a good idea. Indeed, other keyring related stuff breaks if I do that.
You can tell the keyring daemon not to provide ssh-agent services. Perhaps doing that and using the ssh-agent from openssh (which I believe is still started automatically if no agent is running already).
To disable ssh services in gnome-keyring-daemon:
gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false
Some very thin documentation on gnome-keyring-daemon's ssh handling is at: http://live.gnome.org/GnomeKeyring/Ssh
Paul W. Frields wrote:
Does this page help you at all? http://live.gnome.org/GnomeKeyring/Ssh
Sadly, I think that page has less information on it than it used to. You used to be able to tell the keyring daemon to ignore certain ssh keys. That's no longer possible with later versions AFAICT.
I do appreciate the efforts of the gnome keyring folks, but the documentation is sorely lacking, and having undocumented magic in the area of crypto key handling is not something that gives me warm fuzzies.
But then, this isn't really different from many of the newer gnome technologies. Writing good and thorough documentation isn't fun, but not writing much at all just leaves users annoyed when they need to do something that isn't at all obvious.
Robert Nichols rnicholsNOSPAM@comcast.net writes:
Thereafter, ssh happily without requiring a passphrase, and that capability does _not_ time out.
Another thing that appears not to work with the gnome version of the ssh-agent is "ssh-add -d" or "ssh-add -D". Not good.
-wolfgang
Todd Zullinger wrote:
Robert Nichols wrote:
The process at the other end of $SSH_AUTH_SOCK is "gnome-keyring-daemon -d -login". That process gets created when I log in. Killing it doesn't strike me as a good idea. Indeed, other keyring related stuff breaks if I do that.
You can tell the keyring daemon not to provide ssh-agent services. Perhaps doing that and using the ssh-agent from openssh (which I believe is still started automatically if no agent is running already).
To disable ssh services in gnome-keyring-daemon:
gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false
Some very thin documentation on gnome-keyring-daemon's ssh handling is at: http://live.gnome.org/GnomeKeyring/Ssh
Again, thanks for the effort, but NO-GO!
I tried changing the setting for that boolean to false, both with gconftool-2 and with the GUI gconf-editor, and also by running gconftool-2 as root. No change, nada, zip! Log out, log back in, reboot, ..., no change at all. Unsetting the environment variable for SSH_ASKPASS (edited /etc/profile.d/gnome-ssh-askpass.sh so that the variable never gets set) changes nothing. The only thing that has an effect is unsetting SSH_AUTH_SOCK, and doing that means that the passphrase is required _every_time_.
If SSH_AUTH_SOCK is unset or the socket is not present, ssh-add fails with "Could not open a connection to your authentication agent." Looks like the only options are (a) use gnome-keyring-daemon and accept that the key is unlocked forever, or (b) use nothing and enter the passphrase every time.
Robert Nichols wrote, On 03/03/2009 02:29 PM:
Todd Zullinger wrote:
Robert Nichols wrote:
The process at the other end of $SSH_AUTH_SOCK is "gnome-keyring-daemon -d -login". That process gets created when I log in. Killing it doesn't strike me as a good idea. Indeed, other keyring related stuff breaks if I do that.
You can tell the keyring daemon not to provide ssh-agent services. Perhaps doing that and using the ssh-agent from openssh (which I believe is still started automatically if no agent is running already).
To disable ssh services in gnome-keyring-daemon:
gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false
Some very thin documentation on gnome-keyring-daemon's ssh handling is at: http://live.gnome.org/GnomeKeyring/Ssh
Again, thanks for the effort, but NO-GO!
I tried changing the setting for that boolean to false, both with gconftool-2 and with the GUI gconf-editor, and also by running gconftool-2 as root. No change, nada, zip! Log out, log back in, reboot, ..., no change at all. Unsetting the environment variable for SSH_ASKPASS (edited /etc/profile.d/gnome-ssh-askpass.sh so that the variable never gets set) changes nothing. The only thing that has an effect is unsetting SSH_AUTH_SOCK, and doing that means that the passphrase is required _every_time_.
If SSH_AUTH_SOCK is unset or the socket is not present, ssh-add fails with "Could not open a connection to your authentication agent." Looks like the only options are (a) use gnome-keyring-daemon and accept that the key is unlocked forever, or (b) use nothing and enter the passphrase every time.
I am not sure where to modify it now days, but IIRC ssh-agent is started before your window manager is going in the xinitrc. it used to be around line 62 of /etc/X11/xinit/xinitrc-common
My guess is the -t needs applied to THAT instance of ssh-agent.
Todd Denniston wrote:
Robert Nichols wrote, On 03/03/2009 02:29 PM:
Again, thanks for the effort, but NO-GO!
I tried changing the setting for that boolean to false, both with gconftool-2 and with the GUI gconf-editor, and also by running gconftool-2 as root. No change, nada, zip!
Well, all that would do is prevent the gnome-keyring-daemon from being your ssh-agent. You _should_ then have the openssh ssh-agent, which would be configurable in a more documented way.
If SSH_AUTH_SOCK is unset or the socket is not present, ssh-add fails with "Could not open a connection to your authentication agent."
Sure. No surprises there.
Looks like the only options are (a) use gnome-keyring-daemon and accept that the key is unlocked forever, or (b) use nothing and enter the passphrase every time.
I can't imagine those are the only choices. :)
I am not sure where to modify it now days, but IIRC ssh-agent is started before your window manager is going in the xinitrc. it used to be around line 62 of /etc/X11/xinit/xinitrc-common
My guess is the -t needs applied to THAT instance of ssh-agent.
Actually, modifying the ssh-agent invocation shouldn't even be needed. The -t option to ssh-add should do this. It just doesn't work with the gnome-keyring-daemon's ssh agent, but it should work with the openssh ssh agent.
Bob, when you set /apps/gnome-keyring/daemon-components/ssh to false (as your user), does that change what program is providing the SSH_AUTH_SOCK?
I think the first step is to verify that you're replacing the gnome-keyring-daemon ssh agent with the openssh ssh agent. It seems to me that the features you are looking to use are not implemented in gnome-keyring-daemon.
On Mon, Mar 2, 2009 at 11:06 PM, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
After I've used ssh on a connection with RSA authorization and given my keyring's passphrase to gnome-ssh-askpass, that keyring is now unlocked and future connections can be made without the passphrase. Is there a way, short of logging out and back in, to make the passphrase required again for a connection? I'd rather not have to uninstall or disable openssh-askpass since it's nice not to have to supply a lengthy passphrase repeatedly when needed in a short period, but I really don't like leaving that key open indefinitely.
In searching for info I keep getting references to ssh-agent being responsible for remembering the key, but I find that ssh-agent is never executed on my system.
I'm running currently updated Fedora 10 with Gnome.
This is how I do it: Configure the system to boot into runlevel 3. At the CLI type (use backticks): ssh-agent `exec startx' Load the keys --passphrase required only once. Lock the agent --blank spaces count on this password.
From there on, the ssh-agent will be available until you reboot or
log out completely.
Read the man pages: ssh-add, ssh-agent for more info. ~af
I wrote:
Bob, when you set /apps/gnome-keyring/daemon-components/ssh to false (as your user), does that change what program is providing the SSH_AUTH_SOCK?
I think the first step is to verify that you're replacing the gnome-keyring-daemon ssh agent with the openssh ssh agent. It seems to me that the features you are looking to use are not implemented in gnome-keyring-daemon.
Testing this myself, it seems that gnome-keyring-daemon is still setting SSH_AUTH_SOCK even after being told not to provide an ssh agent. Bah! I guess it knows better than I what I want. ;)
Todd Denniston wrote:
Robert Nichols wrote, On 03/03/2009 02:29 PM:
Todd Zullinger wrote:
[SNIP]
To disable ssh services in gnome-keyring-daemon:
gconftool-2 --set -t bool /apps/gnome-keyring/daemon-components/ssh false
Some very thin documentation on gnome-keyring-daemon's ssh handling is at: http://live.gnome.org/GnomeKeyring/Ssh
Again, thanks for the effort, but NO-GO!
I tried changing the setting for that boolean to false, both with gconftool-2 and with the GUI gconf-editor, and also by running gconftool-2 as root. No change, nada, zip! Log out, log back in, reboot, ..., no change at all. Unsetting the environment variable for SSH_ASKPASS (edited /etc/profile.d/gnome-ssh-askpass.sh so that the variable never gets set) changes nothing. The only thing that has an effect is unsetting SSH_AUTH_SOCK, and doing that means that the passphrase is required _every_time_.
If SSH_AUTH_SOCK is unset or the socket is not present, ssh-add fails with "Could not open a connection to your authentication agent." Looks like the only options are (a) use gnome-keyring-daemon and accept that the key is unlocked forever, or (b) use nothing and enter the passphrase every time.
I am not sure where to modify it now days, but IIRC ssh-agent is started before your window manager is going in the xinitrc. it used to be around line 62 of /etc/X11/xinit/xinitrc-common
My guess is the -t needs applied to THAT instance of ssh-agent.
Sorry, but in /etc/X11/xinit/Xsession I find that SSH_AGENT is not used with Gnome:
case "$1" in failsafe) exec -l $SHELL -c "xterm -geometry 80x24-0-0" ;; gnome|gnome-session) # lack of SSH_AGENT is intentional, see #441123. though # the whole thing should really happen in xinitrc.d anyway. exec -l $SHELL -c gnome-session exec /bin/sh -c "exec -l $SHELL -c "gnome-session"" ;; kde|kde1|kde2) exec $SSH_AGENT /bin/sh -c "exec -l $SHELL -c "startkde"" ;; ...
On 03/03/2009 02:06 AM, Robert Nichols wrote:
After I've used ssh on a connection with RSA authorization and given my keyring's passphrase to gnome-ssh-askpass, that keyring is now
Here's what I do. The gnome pasphrase gui I find very unfriendly as it steals and locks focus so you cannot do anything else. So I prefer the standard tools.
Goal: make sure we are using the real ssh-agent but do not rely on gnome/X etc to set this up for us. By all means tell gnome (as someone suggested) to not act as ssh-agent.
I use a file to communicate the ssh-agent socket info for later use and thus can be run anytime - we do not need a parent X or gnome process to start things off.
(1) Create a shell script (I put my version below) which starts ssh-agent and keeps the socket info in a convenient place for any shell to get later
(2) I put it in ~/etc/profile.d/ssh-agent-start.sh
(3) Make sure it is executable
% chmod +x ~/etc/profile.d/ssh-agent-start.sh
(4) Append .bash_profile with this snippet:
# End of .bash_profile
# Run (source) any executable in our ~/etc/profile.d # which ends in .sh
for i in ${HOME}/etc/profile.d/*.sh ; do if [ -r "$i" -a -x "$i" ]; then if [ "$PS1" ]; then . $i else . $i &>/dev/null fi fi done
(5) Append this to end of .bashrc
# End of .bashrc for i in ${HOME}/etc/profile.d/*.sh ; do if [ -r "$i" -a -x "$i" ]; then if [ "$PS1" ]; then . $i else . $i &>/dev/null fi fi done
(6) You can then just use in a terminal You do not need to logout but please start a new shell - fresh terminal will do just fine.
ssh-add or ssh-add -t bla bla
(7) For convenience I put a launcher button on the taskbar so i can click and get a GUI prompt for the passphrase. Some prefer to auto run this on login - I prefer not to.
This launcher simply runs the following 2 commands (which you can wrap into a 2 line script)
. ${HOME}/etc/profile.d/ssh-agent-start.sh /usr/bin/ssh-add
This works for me.
gene/
This shud be an attachment but attachments are frowned on in mailing lists. Sorry.
========== ~/etc/profile.d/ssh-agent-start.sh =============== #!/bin/bash # Please put me in ~/etc/profile.d # I store ssh-agent env info in ~/.ssh-agent-info so later shells # do not need to be child process. # gene - 2009
agent="/usr/bin/ssh-agent" info=${HOME}/.ssh-agent-info #askpass="/usr/bin/ksshaskpass" askpass="/usr/libexec/openssh/ssh-askpass"
start_agent () { eval "$agent | egrep -v 'echo Agent pid' > $info" . $info SSH_ASKPASS=$askpass echo "SSH_ASKPASS=$askpass ; export SSH_ASKPASS;" >> $info }
if [ -f $info ] ; then . $info > /dev/null 2>&1 fi
if [ -x $agent ] ; then if [ -z "${SSH_AUTH_SOCK}" ] ; then ## NOTE: a root login will kill *all* users' ssh-agents #echo "no SSH_AUTH_SOCK - starting" killall ssh-agent start_agent else # Gnome sets SSH_AUTH_SOCK but unlike ssh-agent - it does # not set SSH_AGENT_PID in of ssh-agent - so we use this # Should probably check if I am the owner of the process too ... if [ -z "$SSH_AGENT_PID" ] ; then #echo "no SSH_AGENT_PID - starting" start_agent else pid=${SSH_AGENT_PID} runningpid=$(ps -p $pid -o pid= | sed -e 's# ##') if [ x"$runningpid" = "x" -o x"$pid" != x"$runningpid" ] then # not running #echo "no running agent on pid $pid" start_agent else if [ -f $info ] ; then . $info else #echo "Missing $info .. starting agent" start_agent fi fi fi fi fi # =================== End of ssh-agent-start.sh =================
Wolfgang S. Rupprecht wrote:
Another thing that appears not to work with the gnome version of the ssh-agent is "ssh-add -d" or "ssh-add -D". Not good.
I think you're confused by the fact that the identities are still listed by "ssh-add -l". They're certainly deactivated and require a passphrase in order to be used again (tested in GNOME 2.24).
Todd Zullinger wrote:
I do appreciate the efforts of the gnome keyring folks, but the documentation is sorely lacking, and having undocumented magic in the area of crypto key handling is not something that gives me warm fuzzies.
I believe the documentation wasn't written because services were intended to be identical to ssh-agent. The "ssh-add" tool can still be used to add and remove identities, and has its own man page.
Gordon Messmer wrote:
I believe the documentation wasn't written because services were intended to be identical to ssh-agent.
The problem is that it is configured in very different ways than ssh-agent. So it requires it's own documentation.
And further, the services are a long way from identical. :)
The "ssh-add" tool can still be used to add and remove identities, and has its own man page.
Sure, and I find that many of the things documented to work in the ssh-add manpage do not work with the ssh agent provided by gnome keyring.
Are you able to remove identities from the gnome provided agent? I am not. Not with the -d or -D switch.
$ ssh-add -l 1024 61:34:65:0b:eb:cb:2b:83:cf:e2:3d:e9:9f:2f:c5:d3 id_dsa (DSA) 2048 27:c0:40:7c:f2:e5:4b:20:23:6b:19:2a:af:11:e7:6c id_rsa (RSA)
$ ssh-add -D All identities removed.
$ ssh-add -l 1024 61:34:65:0b:eb:cb:2b:83:cf:e2:3d:e9:9f:2f:c5:d3 id_dsa (DSA) 2048 27:c0:40:7c:f2:e5:4b:20:23:6b:19:2a:af:11:e7:6c id_rsa (RSA)
Same for the -t option to have an identity expire, as well as the -x option to lock the agent. In the case of the -x option, ssh-add prompts for a password to lock the agent and then reports "Agent locked." Yet the keys continue to be usable to login to remote systems.
Unless I'm doing something very wrong (which is always a possible), the gnome provided ssh agent is lacking a great many ways.
Perhaps worst of all, I have been unable to disable the gnome ssh agent using the methods at http://live.gnome.org/GnomeKeyring/Ssh . So what little documentation there is appears to be inaccurate. :(
I wrote:
Are you able to remove identities from the gnome provided agent? I am not. Not with the -d or -D switch.
$ ssh-add -l 1024 61:34:65:0b:eb:cb:2b:83:cf:e2:3d:e9:9f:2f:c5:d3 id_dsa (DSA) 2048 27:c0:40:7c:f2:e5:4b:20:23:6b:19:2a:af:11:e7:6c id_rsa (RSA)
$ ssh-add -D All identities removed.
$ ssh-add -l 1024 61:34:65:0b:eb:cb:2b:83:cf:e2:3d:e9:9f:2f:c5:d3 id_dsa (DSA) 2048 27:c0:40:7c:f2:e5:4b:20:23:6b:19:2a:af:11:e7:6c id_rsa (RSA)
And to be clear, I am able to use these keys without any new passphrase prompting.
Gordon Messmer yinyang@eburg.com writes:
Wolfgang S. Rupprecht wrote:
Another thing that appears not to work with the gnome version of the ssh-agent is "ssh-add -d" or "ssh-add -D". Not good.
I think you're confused by the fact that the identities are still listed by "ssh-add -l". They're certainly deactivated and require a passphrase in order to be used again (tested in GNOME 2.24).
No, I'm confused by the fact that I can still ssh to remote machines without entering my key-unlocking passphrase. ;-)
$ ssh-add -D All identities removed. $ ssh localhost Last login: Thu Mar 5 07:03:01 2009 from localhost $
-wolfgang
Wolfgang S. Rupprecht wrote:
Gordon Messmer yinyang@eburg.com writes:
Wolfgang S. Rupprecht wrote:
Another thing that appears not to work with the gnome version of the ssh-agent is "ssh-add -d" or "ssh-add -D". Not good.
I think you're confused by the fact that the identities are still listed by "ssh-add -l". They're certainly deactivated and require a passphrase in order to be used again (tested in GNOME 2.24).
No, I'm confused by the fact that I can still ssh to remote machines without entering my key-unlocking passphrase. ;-)
$ ssh-add -D All identities removed. $ ssh localhost Last login: Thu Mar 5 07:03:01 2009 from localhost $
Right, this is clearly a gnome-keyring bug. There are a good number of them it seems.
Not honoring -c or -t is: http://bugzilla.gnome.org/525574 Inability to disable it is: http://bugzilla.gnome.org/558181
The latter is fixed upstream, but only in the gnome-2.25 branch. I don't know if anyone intends to backport the fix to the current stable branch so F-10 can be updated. The changes don't apply cleanly, so it'd take a little bit of work to sort out.
Wolfgang S. Rupprecht wrote:
Gordon Messmer yinyang@eburg.com writes:
I think you're confused by the fact that the identities are still listed by "ssh-add -l". They're certainly deactivated and require a passphrase in order to be used again (tested in GNOME 2.24).
No, I'm confused by the fact that I can still ssh to remote machines without entering my key-unlocking passphrase. ;-)
Like I said, this works properly for me under GNOME 2.24 (F10). Since you didn't include any details of your own setup, I can't comment on why it's not working for you the way that it should.
Gordon Messmer wrote:
Wolfgang S. Rupprecht wrote:
Gordon Messmer yinyang@eburg.com writes:
I think you're confused by the fact that the identities are still listed by "ssh-add -l". They're certainly deactivated and require a passphrase in order to be used again (tested in GNOME 2.24).
No, I'm confused by the fact that I can still ssh to remote machines without entering my key-unlocking passphrase. ;-)
Like I said, this works properly for me under GNOME 2.24 (F10). Since you didn't include any details of your own setup, I can't comment on why it's not working for you the way that it should.
Indeed, it also works for me in F10's GNOME 2.24. I'm the one who started the thread with this question, and a simple "ssh-add -d" does what I need. I'd like to be able to set a timeout, but I can make do with manual re-locking.
I appreciate all who contributed here.
Gordon Messmer wrote:
Todd Zullinger wrote:
Are you able to remove identities from the gnome provided agent? I am not. Not with the -d or -D switch.
Yes, I am. Both -d and -D work properly on GNOME 2.24 in F10.
Same setup here. And it does not work for me. The open bugs I posted indicate that it's not just me and Wolfgang having problems either. You must have the lucky 100th install or something. ;)
The gnome-keyring-daemon's ssh agent is most definitely not as robust as the openssh ssh agent at this time. It's a pity that it can't even be disabled according to its documentation due to yet more bugs (which are apparently fixed upstream, but are not backported to Gnome-2.24 and F-10).
Gordon Messmer yinyang@eburg.com writes:
Wolfgang S. Rupprecht wrote:
Gordon Messmer yinyang@eburg.com writes:
I think you're confused by the fact that the identities are still listed by "ssh-add -l". They're certainly deactivated and require a passphrase in order to be used again (tested in GNOME 2.24).
No, I'm confused by the fact that I can still ssh to remote machines without entering my key-unlocking passphrase. ;-)
Like I said, this works properly for me under GNOME 2.24 (F10). Since you didn't include any details of your own setup, I can't comment on why it's not working for you the way that it should.
I thought I'd posted the details earlier -- if not here they are. F10 64-bit x86 install with daily yum updates. Anything else you need to convince yourself this is a problem?
-wolfgang
Wolfgang S. Rupprecht wrote:
I thought I'd posted the details earlier -- if not here they are. F10 64-bit x86 install with daily yum updates. Anything else you need to convince yourself this is a problem?
I'm curious. I have the same setup (64bit F10), and I don't see the same problem.
If I unlock my key, I can ssh to hosts where it is installed without any prompts, as expected. If I do "ssh-add -D", it prints "All identities removed". Afterward, I'm prompted for my ssh key passphrase. If I cancel the dialog, ssh will ask for my password.
I can imagine a couple of things that might cause the problem that you're seeing, if you have time to do a couple of tests. First, do "ssh-add -D" and then "ssh-add -l". Send the output of the latter command. Also, the output of "set | grep SSH". Then ssh to a host where your key is installed with "ssh -v" and include the output of that command as well. Hopefully one of those three commands will illuminate what's going on.
Thanks, Wolfgang.