On Mon, 2015-02-09 at 18:53 -0800, Russ Allbery wrote: > 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. 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). > 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)? 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.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature