Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange
Hello!
Since three replies came in at once (from my perspective), I'm doing one
email.
On 2/9/2015 6:53 PM, Russ Allbery wrote:
Alfred Karl Kornel <akkornel@stanford.edu> writes:
I am reporting an issue that I have discovered in Debian's OpenSSH
package: It appears that setting GSSAPIKeyExchange overrides the
KexAlgorithms setting.
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.
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.
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)?
Yup, that's correct!
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.
The problem with that is, if I do that I'm putting all of my faith that
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
Reply to: