gnome-keyring-daemon does not honor constrained ssh identities

Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: http://bugzilla.gnome.org/show_bug.cgi?id=525574

the bug has been fixed upstream now

The new version is in karmic now

Bug reopened in gnome, confirmation prompt (ssh-add -c) still not supported.

for anyone using Intrepid, i pass along the following workaround supplied by Daniel Kahn Gillmor (one of the commenters on the upstream bug report linked above):

[begin quote]<blockquote>

sigh. this particular problem is such a confusing mess. it seems like
every piece of software involved is faulty in some way at least,
including ssh-add from the OpenSSH project [0].

my preferred workaround at the moment is to just avoid using the
gnome-keyring PAM module entirely. This is most simply accomplished with:

 aptitude remove libpam-gnome-keyring

though you might also be able to get away with leaving the package
installed, and just commenting out references to it in /etc/pam.d/*

If you opt for the latter approach, be aware that the config files in
/etc/pam.d can occasionally be pretty finicky -- in particular, if
you've got any rules that potentially resolve by skipping over some
fixed number of modules in the stack (e.g. "success=2" means "skip over
the next two modules if this module succeeds) [1]. Anyway, this is just
a warning to say "don't fiddle with /etc/pam.d/* unless you're either
(a) pretty sure about what you're doing, or (b) willing to experiment
and potentially temporarily break your system. I'm all for fiddling
with config files, but those are definitely finicky ones -- a good
learning experience!

After either removing the package or disabling it in the PAM config,
you'll need to log out and log back in to make it so you're using the
traditional SSH agent, which won't have this particular failure mode.

hope this helps,

 --dkg

[0] https://bugzilla.mindrot.org/show_bug.cgi?id=1612
[1]
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html

</blockquote>[end quote]

the aptitude solution worked for me, though i don't know if there might be any reasons to avoid removing libpam-gnome-keyring , so use at your own risk. here's what Daniel said about that risk:

[begin quote]<blockquote>

The drawbacks i've seen to the workaround i proposed are:

 0) the gnome-keyring daemon doesn't get started up during session login
(i think it will get started later, at a point where it can read the
configuration info well enough to not hijack the ssh-agent position)

 1) you may need to remove other packages, if they Depend:
libpam-gnome-keyring -- at one point (i dunno if this is true for your
distro), i believe the gnome metapackage itself depended on
libpam-gnome-keyring, which meant that you'd have to remove the
metapackage (and lose its nice tracking/updating features) in order to
remove the PAM module.

these are subtle changes, but it's probably good to be aware of
them -- hopefully fixing one problem doesn't cause others ;)

</blockquote>[end quote]

This bug was fixed in the package openssh - 1:5.3p1-1ubuntu1

---------------
openssh (1:5.3p1-1ubuntu1) lucid; urgency=low

  * Resynchronise with Debian. Remaining changes:
    - Add support for registering ConsoleKit sessions on login.
    - Drop openssh-blacklist and openssh-blacklist-extra to Suggests; they
      take up a lot of CD space, and I suspect that rolling them out in
      security updates has covered most affected systems now.
    - Convert to Upstart. The init script is still here for the benefit of
      people running sshd in chroots.

openssh (1:5.3p1-1) unstable; urgency=low

  * New upstream release.
  * Update to GSSAPI patch from
    http://www.sxw.org.uk/computing/patches/openssh-5.3p1-gsskex-all-20100124.patch.
  * Backport from upstream:
    - Do not fall back to adding keys without contraints (ssh-add -c / -t
      ...) when the agent refuses the constrained add request. This was a
      useful migration measure back in 2002 when constraints were new, but
      just adds risk now (LP: #209447).
  * Drop change from 1:3.8p1-3 to avoid setresuid() and setresgid() system
    calls. This only applied to Linux 2.2, which it's no longer feasible to
    run anyway (see 1:5.2p1-2 changelog).
 -- Colin Watson <email address hidden> Tue, 26 Jan 2010 13:07:40 +0000

@Hektve87