Debian Bug report logs - #493874
ssh-add -c reports SSH_AGENT_FAILURE and doesn't ask for confirmation

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <wouter@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: ssh-add -c reports SSH_AGENT_FAILURE and doesn't ask for confirmation

Date: Tue, 05 Aug 2008 11:51:49 -0300

Package: openssh-client
Version: 1:5.1p1-2
Severity: normal
File: /usr/bin/ssh-add

Hi,

Since a while, when running 'ssh-add -c' (which is supposed to make
ssh-agent ask the user for confirmation before allowing use of an ssh
key), ssh-add prints "SSH_AGENT_FAILURE" on a line by itself (without
explaining what the exact failure is). The result seems to be that
ssh-agent then does know the key and allows software to use it, but it
does not request user confirmation before giving out the secret key.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.26-1-powerpc
Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages openssh-client depends on:
ii  adduser               3.109              add and remove users and groups
ii  debconf [debconf-2.0] 1.5.23             Debian configuration management sy
ii  dpkg                  1.14.20            Debian package management system
ii  libc6                 2.7-13             GNU C Library: Shared libraries
ii  libcomerr2            1.41.0-3           common error description library
ii  libedit2              2.11~20080614-1    BSD editline and history libraries
ii  libkrb53              1.6.dfsg.4~beta1-3 MIT Kerberos runtime libraries
ii  libncurses5           5.6+20080726-2     shared libraries for terminal hand
ii  libssl0.9.8           0.9.8g-13          SSL shared libraries
ii  passwd                1:4.1.1-3          change and administer password and
ii  zlib1g                1:1.2.3.3.dfsg-12  compression library - runtime

Versions of packages openssh-client recommends:
ii  openssh-blacklist             0.4.1      list of default blacklisted OpenSS
ii  openssh-blacklist-extra       0.4.1      list of non-default blacklisted Op
ii  xauth                         1:1.0.3-2  X authentication utility

Versions of packages openssh-client suggests:
pn  keychain                     <none>      (no description available)
pn  libpam-ssh                   <none>      (no description available)
ii  ssh-askpass                  1:1.2.4.1-7 under X, asks user for a passphras

-- no debconf information

Message #10 received at 493874@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Wouter Verhelst <wouter@debian.org>, 493874@bugs.debian.org

Subject: Re: Bug#493874: ssh-add -c reports SSH_AGENT_FAILURE and doesn't ask for confirmation

Date: Wed, 6 Aug 2008 01:35:13 +0100

On Tue, Aug 05, 2008 at 11:51:49AM -0300, Wouter Verhelst wrote:
> Since a while, when running 'ssh-add -c' (which is supposed to make
> ssh-agent ask the user for confirmation before allowing use of an ssh
> key), ssh-add prints "SSH_AGENT_FAILURE" on a line by itself (without
> explaining what the exact failure is). The result seems to be that
> ssh-agent then does know the key and allows software to use it, but it
> does not request user confirmation before giving out the secret key.

I can't reproduce this:

  <cjwatson@sarantium ~>$ ssh-add -c
  Enter passphrase for /home/cjwatson/.ssh/id_rsa:
  Identity added: /home/cjwatson/.ssh/id_rsa (/home/cjwatson/.ssh/id_rsa)
  The user has to confirm each use of the key

Is it possible that you are not in fact using ssh-agent, but a different
not-quite-compatible agent provided by something like seahorse? Have a
look at what's behind $SSH_AUTH_SOCK.

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #15 received at 493874@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <w@uter.be>

To: Colin Watson <cjwatson@debian.org>

Cc: 493874@bugs.debian.org

Subject: Re: Bug#493874: ssh-add -c reports SSH_AGENT_FAILURE and doesn't ask for confirmation

Date: Wed, 6 Aug 2008 01:28:19 -0300

On Wed, Aug 06, 2008 at 01:35:13AM +0100, Colin Watson wrote:
> On Tue, Aug 05, 2008 at 11:51:49AM -0300, Wouter Verhelst wrote:
> > Since a while, when running 'ssh-add -c' (which is supposed to make
> > ssh-agent ask the user for confirmation before allowing use of an ssh
> > key), ssh-add prints "SSH_AGENT_FAILURE" on a line by itself (without
> > explaining what the exact failure is). The result seems to be that
> > ssh-agent then does know the key and allows software to use it, but it
> > does not request user confirmation before giving out the secret key.
> 
> I can't reproduce this:
> 
>   <cjwatson@sarantium ~>$ ssh-add -c
>   Enter passphrase for /home/cjwatson/.ssh/id_rsa:
>   Identity added: /home/cjwatson/.ssh/id_rsa (/home/cjwatson/.ssh/id_rsa)
>   The user has to confirm each use of the key
> 
> Is it possible that you are not in fact using ssh-agent, but a different
> not-quite-compatible agent provided by something like seahorse? Have a
> look at what's behind $SSH_AUTH_SOCK.

Yes, that does appear to be the case; $SSH_AUTH_SOCK seems to be served
by gnome-agent. I apparently also can't get rid of it without removing
gdm.

Sigh. Why do the gnome people have to be so insane? Oh well.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Message #20 received at 493874@bugs.debian.org (full text, mbox, reply):

From: Colin Watson <cjwatson@debian.org>

To: Wouter Verhelst <w@uter.be>, 493874@bugs.debian.org

Subject: Re: Bug#493874: ssh-add -c reports SSH_AGENT_FAILURE and doesn't ask for confirmation

Date: Wed, 6 Aug 2008 17:27:27 +0100

On Wed, Aug 06, 2008 at 01:28:19AM -0300, Wouter Verhelst wrote:
> On Wed, Aug 06, 2008 at 01:35:13AM +0100, Colin Watson wrote:
> > Is it possible that you are not in fact using ssh-agent, but a different
> > not-quite-compatible agent provided by something like seahorse? Have a
> > look at what's behind $SSH_AUTH_SOCK.
> 
> Yes, that does appear to be the case; $SSH_AUTH_SOCK seems to be served
> by gnome-agent. I apparently also can't get rid of it without removing
> gdm.

There's no match for "gnome-agent" in dists/unstable/Contents-i386.gz.
Would you mind figuring out the correct package and reassigning this
bug?

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]

Message #25 received at 493874@bugs.debian.org (full text, mbox, reply):

From: Wouter Verhelst <w@uter.be>

To: Colin Watson <cjwatson@debian.org>

Cc: 493874@bugs.debian.org, control@bugs.debian.org

Subject: Re: Bug#493874: ssh-add -c reports SSH_AGENT_FAILURE and doesn't ask for confirmation

Date: Thu, 7 Aug 2008 11:16:45 -0300

reassign 493874 gnome-keyring
severity 493874 wishlist
thanks

On Wed, Aug 06, 2008 at 05:27:27PM +0100, Colin Watson wrote:
> On Wed, Aug 06, 2008 at 01:28:19AM -0300, Wouter Verhelst wrote:
> > On Wed, Aug 06, 2008 at 01:35:13AM +0100, Colin Watson wrote:
> > > Is it possible that you are not in fact using ssh-agent, but a different
> > > not-quite-compatible agent provided by something like seahorse? Have a
> > > look at what's behind $SSH_AUTH_SOCK.
> > 
> > Yes, that does appear to be the case; $SSH_AUTH_SOCK seems to be served
> > by gnome-agent. I apparently also can't get rid of it without removing
> > gdm.
> 
> There's no match for "gnome-agent" in dists/unstable/Contents-i386.gz.
> Would you mind figuring out the correct package and reassigning this
> bug?

Sorry; it was 'gnome-keyring', which runs 'gnome-keyring-daemon'. I got
confused by the fact that ssh calls it an 'agent'.

To the maintainer of gnome-keyring: ssh-add has a '-c' option, which
will cause ssh-add to request from ssh-agent that it requests
confirmation from the user every time an application tries to access the
key; this is a benefit security-wise. It would be nice if gnome-keyring
were to implement this.

-- 
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Message #34 received at 493874@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: 516230@bugs.debian.org, 493874@bugs.debian.org

Subject: #516230 in combination with #493874 creates a serious issue

Date: Sun, 15 Mar 2009 21:05:00 -0400

[Message part 1 (text/plain, inline)]

hey folks--

#493874 (gnome-keyring doesn't ask for confirmation with ssh keys), in
combination with #516230 (gnome-keyring daemon acts as ssh-agent even
when instructed not to) causes a potentially serious security problem.

In particular, people who use ssh-agent regularly, and expect to receive
confirmation before use of their keys are at risk.  Since the default
debian desktop installs gnome, and gnome installs gnome-keyring, those
users are at a serious risk of having their keys available for
non-confirmed use.

if gnome-keyring is unable to honor a constraint requested by a user, it
should *not* import the key in the first place and fail hard, as opposed
to importing it and ignoring the requested constraint.

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Message #39 received at 493874@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: 493874@bugs.debian.org

Cc: control@bugs.debian.org, Wouter Verhelst <wouter@debian.org>

Subject: reported upstream with a patch

Date: Thu, 06 Aug 2009 18:01:51 -0400

[Message part 1 (text/plain, inline)]

forwarded 493874 https://bugzilla.mindrot.org/show_bug.cgi?id=1612
thanks

So i looked into this further.  And while gnome-keyring has dubious
behavior, it actually correctly reports when it does not support
constraints.  See the discussion with gnome folks here:

  https://bugzilla.gnome.org/show_bug.cgi?id=525574

The most serious bug is in ssh-add, which sees the failure to add-key
with constraints, and then goes ahead and tries to re-submit the key
*without* constraints.  I've reported this to openssh upstream, along
with a patch:

  https://bugzilla.mindrot.org/show_bug.cgi?id=1612

they seem to be indicating (via bugzilla bug blocking/dependency trees)
that the patch will be incorporated into OpenSSH by version 5.4.

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.