Good morning!

I am reporting an issue that I have discovered in Debian's OpenSSH package:
It appears that setting GSSAPIKeyExchange overrides the KexAlgorithms setting.

The group I am in (Authentication & Collaboration Solutions, part of Stanford
IT) relies heavily on Kerberos: It is our policy to not allow our group
members to enter passwords in remote sites, with few exceptions.

As a new employee in our group, I have been updating our internal
documentation that documents how we use SSH.  Part of that includes making a
standard OpenSSH client configuration for other new employees to use.  One of
the items in this configuration is to enable GSSAPI key exchange, and also to
disable certain key-exchange algorithms.

The problem I found is, if I explicitly set KexAlgorithms, that essentially
turns off GSSAPIKeyExchange.  Looking at debug logs, OpenSSH does not even try
to use GSSAPI key exchange, which makes me think that setting KexAlgorithms
somehow overrides whatever changes GSSAPIKeyExchange is trying to make.

I'm going to try reproducing this problem in openssh 6.7p1-3, just to make
sure the problem still exists there; I'll report back when I'm able to
reproduce.

found 777549 openssh/1:6.7p1-3
thank you


Hello!

It looks to me like this issue also exists in the latest version, on sid.

I checked this by grabbing openssh_6.7p1.orig.tar.gz and
openssh_6.7p1-3.debian.tar.xz off of packages.debian.org, and then
applying gssapi.patch to the source.

I see that the GSSAPI key-exchange algorithms are added to the head of
the proposal in sshconnect2.c lines 170-188.  Then, on lines 222-223,
the client checks to see if any key-exchange algorithms were specified
as options; if they were, the existing contents of the proposal get
blown away.

I was wondering if the block of code from lines 170-188 could be merged
into the "#ifdef GSSAPI" block that exists at lines 227-236.  Those
lines appear after the key-exchange algorithms proposal gets potentially
blown away, so I think it would be safe to change at that point.

I'm sorry that I'm unable to build and test right now, but I don't have
any hardware (physical or virtual) that I can test on.  If that changes,
I'll let you know!

~ Karl

Alfred Karl Kornel <akkornel@stanford.edu> writes:

Yeah, I would expect this, since GSS-API key exchange *is* a key exchange
mechanism.  If you do GSS-API key exchange, that completely replaces the
normal ssh public key negotiation, since it instead uses Kerberos to
negotiate the encrypted channel with the server.

Is the problem that you want to be able to control the key exchange
algorithms that the server falls back on if GSS-API key exchange fails
(if, for example, the client doesn't support it)?

If you're happy to require all clients to do GSS-API key exchange, you can
just delete all public keys for the server.  They're not used at all with
GSS-API, and that will prevent the server from negotiating any public key
exchange mechanism as a fallback.

Alfred Karl Kornel <akkornel@stanford.edu> writes:

Yeah, I would expect this, since GSS-API key exchange *is* a key exchange
mechanism.  If you do GSS-API key exchange, that completely replaces the
normal ssh public key negotiation, since it instead uses Kerberos to
negotiate the encrypted channel with the server.

Is the problem that you want to be able to control the key exchange
algorithms that the server falls back on if GSS-API key exchange fails
(if, for example, the client doesn't support it)?

If you're happy to require all clients to do GSS-API key exchange, you can
just delete all public keys for the server.  They're not used at all with
GSS-API, and that will prevent the server from negotiating any public key
exchange mechanism as a fallback.

Well what is "normal"... the other KEX algos als differ quite a bit,
e.g. take DH-GEX where you have the additional group exchange.

Guess the main problem here is, that GSSAPI Kex should have become
configurable via KexAlgorithms and not via a separate option.
OTOH, The GSSAPI Kex is really quite special (IIRC the client
authentication phase also happens during the kex then).
I think it would be a severe bug if SSH would fall back to something
else, when one can't configure this something else (i.e. to be nothing).
Cause that may very well be what's desired, i.e. GSSAPI KEX or fail.

Unfortunately SSH has some such "hidden" fallbacks, which I'm quite
unhappy with, from a security POV.

Anyway,... best chances are if Alfred would report this to upstream
(which is here not OpenSSH, but the maintainers of the patchset).

Cheers,
Chris.

Christoph Anton Mitterer <calestyo@scientia.net> writes:

That's also true, particularly since it sounded from the second message
like he has a proposed fix.  However, it's worth noting that any fix for
this wouldn't make it into jessie at this point, so you'll want to be
thinking about workarounds or planning on backporting a later version.

It does make sense to me that it should be possible to both enable GSS-API
key exchange and otherwise restrict the key exchange methods that the
server will use in the absence of GSS-API.  (Ideally, you could restrict
which specific GSS-API key exchange algorithms would be used, but I think
there aren't many to choose from anyway.)

This whole thing is unnecessarily irritating due to the OpenSSH project's
unwillingness to take the key exchange patches, forcing every distribution
to apply them separately and meaning that they aren't considered when
upstream works on things like the configuration parameter for key exchange
methods.

Hello!

Since three replies came in at once (from my perspective), I'm doing one
email.

That's what I thought, but as I understood the patch, it seems that
turning on GSSAPIKeyExchange is just working out what GSSAPI
key-exchange methods are supported, and then prepending those to the
default list of key-exchange algorithms (and then adding "null" at the
end).  That way, if the server doesn't support GSSAPI key exchange, the
client is able to fall back to one of the more traditional methods.

Yup, that's correct!
GSSAPI will be working on both ends.  I don't want to trust in GSSAPI
not working if something goes wrong on my client.  For example, if
Kerberos is messed up on my workstation, I could still securely log in
to the server, I'd just have a coworker log in and get the host key
fingerprint for me.


On 2/9/2015 7:09 PM, Christoph Anton Mitterer wrote:> On Mon, 2015-02-09
at 18:53 -0800, Russ Allbery wrote:
 ><<<snip>>>
 >
 > Guess the main problem here is, that GSSAPI Kex should have become
 > configurable via KexAlgorithms and not via a separate option.
 > OTOH, The GSSAPI Kex is really quite special (IIRC the client
 > authentication phase also happens during the kex then).

Well, I'm find with just having GSSAPIKeyExchange prepend all of the
GSSAPI methods to the start of my chosen KexAlgorithms list.  You could
easily get very complicated here, such as by having SSH recognize things
like "gssapi-group1" or "gssapi-group-exchange", and then replace with
the appropriate expansions (after working out the OIDs).

 ><<<snip>>>
 >
 > Anyway,... best chances are if Alfred would report this to upstream
 > (which is here not OpenSSH, but the maintainers of the patchset).

I was wondering if this would need to go upstream, but from what I
understood, bug reporters are supposed to report bugs directly to Debian.

Could you please tell me where "upstream" is in this case?  I did some
quick searching, but the one place I found hadn't been updated in a few
years.

Once I know where to send the bug report, I'm happy to file it upstream!


On 2/9/2015 7:18 PM, Russ Allbery wrote:
 ><<<snip>>>
 >
 > That's also true, particularly since it sounded from the second message
 > like he has a proposed fix.  However, it's worth noting that any fix for
 > this wouldn't make it into jessie at this point, so you'll want to be
 > thinking about workarounds or planning on backporting a later version.

Yeah, it's really depressing, but I guess that's what's gonna happen.
Could it possibly make it into jessie-backports, or is that also too
much to hope for?

Either way, thanks very much for the quick reply to my bug report!

~ Karl

Karl Kornel <akkornel@stanford.edu> writes:

I thought you said that your policy required Kerberos authentication?  If
Kerberos is messed up on your workstation, that's not going to work.  :)

But in any event there will certainly be people who want to enable GSSAPI
but not require it, so it seems like a useful fix.

There isn't any particular policy about this.  It's always okay to report
the bug directly to upstream (well, unless upstream doesn't want the bug
reports, but pretty sure that's not the case here).  Some Debian package
maintainers really prefer reporters to send the bug there first.  I think
Debian should accept bugs for its packages, but once identified as an
upstream bug, often it's more effective for the reporter to talk to
upstream directly instead of Debian being in the middle of the discussion.

https://github.com/SimonWilkinson/gss-openssh/ so far as I know.  I'm not
sure why the latest commit there is from 2011, since I know there's a
newer version of the patch than that.  Maybe Colin did the last update
himself?

That's certainly possible.

Simon hasn't produced any updates that I'm aware of since 5.6p1, and I
wasn't willing to block OpenSSH upgrades indefinitely waiting for that,
so I've been doing them myself to the best of my ability.  Fortunately
there are generally only relatively minor conflicts and adjustments
involved, and sometimes making sure that code is kept up to date with
changes to OpenSSH's internal APIs.

Well at least it should be absolutely obvious and controllable for an
admin, which methods are used and which are forbidden.
I think automatic/hidden fallbacks are generally a security problem
(unless of course one they are simply part of default options, which one
can override.
Well... unfortunately upstream blocks (or at least shows no interest in)
many things that might be nice or security relevant :(


Cheers,
Chris.

Hmm that could be the case,.. at least it's like that for the
authentication methods.
When GSSAPI Kex on the client, that it automatically prepends
"gssapi-keyex" (not to be confused with gssapi-with-mic).

But you can just manually add this to your preferred auth method list as
well, e.g. I have set
PreferredAuthentications        gssapi-keyex,gssapi-with-mic,hostbased,publickey,keyboard-interactive,password
even though I've disabled GSSAPI key exhanged.

Have you tried similar for the KeyAlogs, and wheter it works out if you
don't put it in the beginning?


Cause then the behaviour would seem more reasonable again,..
Setting GSSAPIKeyExchange adds the respective algo names to the
preference lists when enabled - even though I'd probably prefer it the
patch drops the GSSAPIKeyExchange option, and just always adds the algos
to the default lists (where people could still take them away if they
like).
Well I guess it depends who you end up with,... I generally think it's
okay to report it against Debian, but sometimes I've earned quite
hostile reactions.

I rather meant that you likely have more success in this being sorted
out when you directly ask upstream :)
The URL Russ gave you is probably the best start...
Simon (=upstream) told me that
https://github.com/gss-openssh/openssh-portable is intended to become
the new upstream location, but it seems to be inactive as well, and one
cannot file issues there.


Cheers,
Chris.

That was unintentional, and has been rectified.  I am somewhat surprised
that no one thought to pester me about it, as the person who made the
latest commit to that repository, but it is true that there have been more
pressing issues for me than the gss-openssh patchset of late.

Hi Ben.
Thanks for the hint.

I've forwarded my old bugs there.


Cheers,
Chris.