Debian Bug report logs - #513235
ssh tries the keys proposed by the agent before those passed with -i

Reply or subscribe to this bug.

Toggle useless messages

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

From: Bjørn Mork <bjorn@mork.no>

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

Subject: gnome-keyring: selects wrong key when multiple ssh identities are used

Date: Tue, 27 Jan 2009 15:43:55 +0100

Package: gnome-keyring
Version: 2.22.3-2
Severity: critical
Tags: security
Justification: breaks unrelated software

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

/usr/bin/gnome-keyring-daemon breaks ssh as detailed below, justifying critical
severity.  The breakage may lead to information leakage due to the unexpected
behaviour it causes for ssh.

I regularily log into a system which uses different ssh keys to select different 
configurations.  This fails if gnome-keyring-daemon is running.  It seems to use
previously learned keys even if you specify "ssh -i <keyfile>", or use the
IdentityFile keyword in ~/.ssh/config.

Example ssh session with gnome-keyring-daemon (after already authenticating 
with the remote server using another key):


bjorn@nemi:~$ ssh -v rocs2
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/bjorn/.ssh/config
debug1: Applying options for rocs2
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to login.example.com [10.1.1.82] port 22.
debug1: Connection established.
debug1: identity file /home/bjorn/.ssh/key2 type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5
debug1: match: OpenSSH_4.5 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 zlib@openssh.com
debug1: kex: client->server aes128-cbc hmac-md5 zlib@openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'login.example.com' is known and matches the DSA host key.
debug1: Found key in /home/bjorn/.ssh/known_hosts:15
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: 
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).



Notice the difference after stopping gnome-keyring-daemon:

bjorn@nemi:~$ ssh -v rocs2
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/bjorn/.ssh/config
debug1: Applying options for rocs2
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to login.example.com [10.1.1.82] port 22.
debug1: Connection established.
debug1: identity file /home/bjorn/.ssh/key2 type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5
debug1: match: OpenSSH_4.5 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 zlib@openssh.com
debug1: kex: client->server aes128-cbc hmac-md5 zlib@openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'login.example.com' is known and matches the DSA host key.
debug1: Found key in /home/bjorn/.ssh/known_hosts:115
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/bjorn/.ssh/key2
debug1: read PEM private key done: type DSA
debug1: Remote: Adding to environment: SSH_TARGET=key2
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).

Notice how the second example actually uses the key "key2", which causes
the server to set a specific environment.

I don't know if it's necessary to mention this, but the fact that a clean
Debian installation will run gnome-keyring-daemon by default, and that
the manpage of gnome-keyring-daemon doesn't mention it's ssh-agent 
behaviour at all, makes it all worse.  Trying to find out which part of
the system was breaking ssh was quite an adventure, and I guess I would
have given up making ssh work again if I didn't know that ssh was working
on a lenny system using KDM instead if GDM.

Please fix before releasing lenny.  Or at least disable gnome-keyring-daemon
on default installations.

Thanks,
Bjorn

- -- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gnome-keyring depends on:
ii  gconf2                        2.22.0-1   GNOME configuration database syste
ii  libatk1.0-0                   1.22.0-1   The ATK accessibility toolkit
ii  libc6                         2.7-18     GNU C Library: Shared libraries
ii  libcairo2                     1.6.4-7    The Cairo 2D vector graphics libra
ii  libdbus-1-3                   1.2.1-5    simple interprocess messaging syst
ii  libgconf2-4                   2.22.0-1   GNOME configuration database syste
ii  libgcrypt11                   1.4.1-1    LGPL Crypto library - runtime libr
ii  libglib2.0-0                  2.16.6-1   The GLib library of C routines
ii  libgtk2.0-0                   2.12.11-4  The GTK+ graphical user interface 
ii  libhal-storage1               0.5.11-8   Hardware Abstraction Layer - share
ii  libhal1                       0.5.11-8   Hardware Abstraction Layer - share
ii  libpango1.0-0                 1.20.5-3   Layout and rendering of internatio
ii  libtasn1-3                    1.4-1      Manage ASN.1 structures (runtime)

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring          2.22.3-2   PAM module to unlock the GNOME key

gnome-keyring suggests no packages.

- -- no debconf information

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkl/HacACgkQ10rqkowbIsm/eQCZAdf0ilE1miMV9PgpxqCCjtKT
1lwAnAmhK2y0dpJyXvt+EeOvLGUXBdJE
=21FK
-----END PGP SIGNATURE-----

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

From: Josselin Mouette <joss@debian.org>

To: Bjørn Mork <bjorn@mork.no>, 513235@bugs.debian.org

Subject: Re: Bug#513235: gnome-keyring: selects wrong key when multiple ssh identities are used

Date: Tue, 27 Jan 2009 16:02:58 +0100

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

severity 513235 important
thanks

Le mardi 27 janvier 2009 à 15:43 +0100, Bjørn Mork a écrit :
> Package: gnome-keyring
> Version: 2.22.3-2
> Severity: critical
> Tags: security
> Justification: breaks unrelated software

No, SSH is not unrelated software. Not only it is related, but it is not
“broken” by this bug.

> I regularily log into a system which uses different ssh keys to select different 
> configurations.  This fails if gnome-keyring-daemon is running.  It seems to use
> previously learned keys even if you specify "ssh -i <keyfile>", or use the
> IdentityFile keyword in ~/.ssh/config.

It would be interesting to see whether this happens if you use ssh-agent
instead of gnome-keyring. If you add the first key to the agent, do you
see the same behavior with "ssh -i key2" ?

My guess is that ssh tries the keys proposed by the agent before those
passed with the -i option. And if this is the case, there is nothing
that can be changed in gnome-keyring-daemon for that.

> Please fix before releasing lenny.  Or at least disable gnome-keyring-daemon
> on default installations.

/usr/share/doc/gnome-keyring/README.Debian documents how to disable the
SSH agent functionality. 

Cheers,
-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

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

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

From: Bjørn Mork <bjorn@mork.no>

To: 513235@bugs.debian.org

Subject: Re: Bug#513235: gnome-keyring: selects wrong key when multiple ssh identities are used

Date: Tue, 27 Jan 2009 16:36:53 +0100

Josselin Mouette <joss@debian.org> writes:

> severity 513235 important
> thanks
>
> Le mardi 27 janvier 2009 à 15:43 +0100, Bjørn Mork a écrit :
>> Package: gnome-keyring
>> Version: 2.22.3-2
>> Severity: critical
>> Tags: security
>> Justification: breaks unrelated software
>
> No, SSH is not unrelated software. Not only it is related, but it is not
> “broken” by this bug.

Well, OK.

But at least to me, ssh and gdm are completely unrelated.  Those were
the two packages I tried to use.  The usage of gnome-keyring was
completely unwanted and unexpected, and breaking ssh was even more
unexpected. 

>> I regularily log into a system which uses different ssh keys to select different 
>> configurations.  This fails if gnome-keyring-daemon is running.  It seems to use
>> previously learned keys even if you specify "ssh -i <keyfile>", or use the
>> IdentityFile keyword in ~/.ssh/config.
>
> It would be interesting to see whether this happens if you use ssh-agent
> instead of gnome-keyring. If you add the first key to the agent, do you
> see the same behavior with "ssh -i key2" ?

Just running ssh-agent isn't a problem.  But you're right that any key
added to the agent seems to be used before other keys.  If I add the key
to ssh-agent, then it will be used first.

Let me add that to the already long list of reasons why I don't run
ssh-agent... 

> My guess is that ssh tries the keys proposed by the agent before those
> passed with the -i option. And if this is the case, there is nothing
> that can be changed in gnome-keyring-daemon for that.

Sure there is.  It seems to add some keys by default.  Which ones? and
why?  ssh-agent does not.

>> Please fix before releasing lenny.  Or at least disable gnome-keyring-daemon
>> on default installations.
>
> /usr/share/doc/gnome-keyring/README.Debian documents how to disable the
> SSH agent functionality. 

Thanks.  That'll save me from having to install kdm I guess.


Bjørn

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

From: Josselin Mouette <joss@debian.org>

To: Bjørn Mork <bjorn@mork.no>, 513235@bugs.debian.org

Cc: debian-ssh@lists.debian.org

Subject: Re: Bug#513235: gnome-keyring: selects wrong key when multiple ssh identities are used

Date: Tue, 27 Jan 2009 17:21:12 +0100

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

reassign 513235 openssh-client
retitle 513235 ssh tries the keys proposed by the agent before those passed with -i
thanks

Le mardi 27 janvier 2009 à 16:36 +0100, Bjørn Mork a écrit :
> >> I regularily log into a system which uses different ssh keys to select different 
> >> configurations.  This fails if gnome-keyring-daemon is running.  It seems to use
> >> previously learned keys even if you specify "ssh -i <keyfile>", or use the
> >> IdentityFile keyword in ~/.ssh/config.
> >
> > It would be interesting to see whether this happens if you use ssh-agent
> > instead of gnome-keyring. If you add the first key to the agent, do you
> > see the same behavior with "ssh -i key2" ?
> 
> Just running ssh-agent isn't a problem.  But you're right that any key
> added to the agent seems to be used before other keys.  If I add the key
> to ssh-agent, then it will be used first.

So indeed, ssh is trying the keys proposed by the agent before those
passed with the -i option. This looks like the root cause to me, since
command-line arguments should have priority over things proposed by an
external process. 

Cheers,
-- 
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

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

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

From: Vincent Bernat <bernat@debian.org>

To: Josselin Mouette <joss@debian.org>

Cc: Bjørn Mork <bjorn@mork.no>, 513235@bugs.debian.org

Subject: Re: Bug#513235: gnome-keyring: selects wrong key when multiple ssh identities are used

Date: Mon, 18 Jan 2016 08:51:51 +0100

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

 ❦ 27 janvier 2009 17:21 +0100, Josselin Mouette <joss@debian.org> :

>> >> I regularily log into a system which uses different ssh keys to select different 
>> >> configurations.  This fails if gnome-keyring-daemon is running.  It seems to use
>> >> previously learned keys even if you specify "ssh -i <keyfile>", or use the
>> >> IdentityFile keyword in ~/.ssh/config.
>> >
>> > It would be interesting to see whether this happens if you use ssh-agent
>> > instead of gnome-keyring. If you add the first key to the agent, do you
>> > see the same behavior with "ssh -i key2" ?
>> 
>> Just running ssh-agent isn't a problem.  But you're right that any key
>> added to the agent seems to be used before other keys.  If I add the key
>> to ssh-agent, then it will be used first.
>
> So indeed, ssh is trying the keys proposed by the agent before those
> passed with the -i option. This looks like the root cause to me, since
> command-line arguments should have priority over things proposed by an
> external process. 

The solution is to use IdentitiesOnly option. The linked bug report
highlights that and there was no real evidence this wasn't working as
expected. It works as expected for me.

I propose to close this bug report (and as I randomly stumbled on it, I
am unlikely to remember that in a few days).
-- 
Suspicion always haunts the guilty mind.
		-- Wm. Shakespeare

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

Send a report that this bug log contains spam.