Ubuntu

gnome-keyring-daemon does not honor constrained ssh identities

Reported by James E. Blair on 2008-03-30
82
This bug affects 9 people
Affects Status Importance Assigned to Milestone
GNOME Keyring
Confirmed
Medium
portable OpenSSH
Fix Released
Unknown
gnome-keyring (Ubuntu)
Medium
Ubuntu Desktop Bugs
openssh (Ubuntu)
High
Colin Watson

Bug Description

Binary package hint: gnome-keyring

The ssh-agent honors adding constrained identities -- where such constraints may be either:
  * Require confirmation each time the agent allows the identity to be used.
  * A maximum lifetime for the identity.

The gnome-keyring-daemon is a replacement for the ssh-agent in Hardy Heron, but does not support those constraints. If the user issues:

  ssh-add -c

or

  ssh-add -t <time value>

The identities will be added without those constraints.

This is especially important in some uses of the ssh-agent, such as ssh-agent forwarding, where the usage of the agent can not be considered secure without the confirmation constraint.

If the gnome-keyring-daemon is intended to replace the ssh-agent in Ubuntu, it should support these important security features -- they were added with good reason.

Sebastien Bacher (seb128) wrote :

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

Changed in gnome-keyring:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Triaged
status: New → Unknown
Changed in gnome-keyring:
status: Unknown → Confirmed

Created an attachment (id=1652)
ssh-add should not retry key addition without constraints if
constraints fail.

When ssh-add tries to add a key to the agent with constraints, and the
agent rejects the addition, ssh-add appears to retry the addition
without constraints.

This is dangerous behavior when the agent does not support certain
constraints. For example, if a user uses an agent (such as the current
ssh-agent implementation in gnome-keyring) that does not support
confirmation or maximum lifetime, then using:

  ssh-add -t 3600

will print an error message but then proceed to re-add the key withut
the constrained lifetime. this causes the agent to retain the key far
past the specified time, an explicit contravention of the user's
declared intent.

I expect more conservative behavior from openssh when handling
sensitive material. Discarding the constraint and retrying should be a
choice left to the user, not taken automatically by ssh-add.

the attached patch should fix this behavior.

Changed in gnome-keyring:
status: Confirmed → In Progress
Sebastien Bacher (seb128) wrote :

the bug has been fixed upstream now

Changed in gnome-keyring (Ubuntu):
status: Triaged → Fix Committed
Sebastien Bacher (seb128) wrote :

The new version is in karmic now

Changed in gnome-keyring (Ubuntu):
status: Fix Committed → Fix Released

Created an attachment (id=1674)
Revised patch

With your patch, we can garbage collect ssh_add_identity() since
nothing calls it anymore.

Patch applied, this will be in openssh-5.4

Mass move of RESOLVED bugs to CLOSED now that 5.3 is out.

Sorry, but the patch doesn't seem to present in the 5.3p1 tarball, and
it also does not appear to be applied to the head of CVS (where i'd
expect it to be for 5.4, which is not yet out).

I'm probably misunderstanding some piece of the workflow, but this
doesn't look resolved to me.

It's been committed to OpenBSD but not yet synced to portable (we
weren't syncing HEAD while we were working on the 5.3p1 release). Now
that 5.3 is out we'll start pulling the changes in again.

See for example:
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/authfd.c

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

Changed in gnome-keyring (Ubuntu):
status: Fix Released → In Progress
Andy Hieb (arh1) wrote :

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]

Colin Watson (cjwatson) on 2010-01-25
Changed in openssh (Ubuntu):
status: New → Fix Committed
importance: Undecided → High
assignee: nobody → Colin Watson (cjwatson)
Launchpad Janitor (janitor) wrote :

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

Changed in openssh (Ubuntu):
status: Fix Committed → Fix Released

With the release of 5.4p1, this bug is now considered closed.

Changed in openssh:
status: Unknown → Fix Released
Changed in gnome-keyring:
status: In Progress → Confirmed
Changed in gnome-keyring:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.