Bug#777549: openssh-client: Setting KexAlgorithms disables GSSAPIKeyExchange
Karl Kornel <akkornel@stanford.edu> writes:
> 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.
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.
> 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.
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.
> Could you please tell me where "upstream" is in this case?
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?
> 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?
That's certainly possible.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: