Reenable MONITOR_REQ_GSSCHECKMIC after gssapi-with-mic failures

[beldmit]

Hopefully fixes #20

MONITOR_REQ_GSSCHECKMIC request type gets forbidden after gssapi-with-mic failures as it is intended to be processed only once.
In case when gssapi-keyex is processed after that, it causes the immediate failure.

Looks like the best possible option is restoring the permission after the authorization is failed and gssapi-keyex is permitted.

[beldmit]

@athos-ribeiro, would you mind to test the patch?
@cjwatson could you please review it?

[athos-ribeiro]

Hi, @beldmit!

Thanks for the fix. I tried it locally with the reproducer described in #20 and the patch does fix the bug in Ubuntu impish.

In case anyone else is interested in testing this, I pushed the Ubuntu package with this patch applied to a PPA at https://launchpad.net/~athos-ribeiro/+archive/ubuntu/openssh-gssapi-fix

[beldmit]

Ping @cjwatson

[nrother]

Any news on this? I'd love to see this fixed!

[cellarweasel]

@Jakuje If this has been approved why is it not being merged? I’m just curious. But I did trace out this bug and find it after much gnashing of teeth so I’m eager to know if these changes are going to be made a default part of Fedora, Debian, and Ubuntu. (maybe even made apart of a bug fix for rhel8 & 9? I need to put in many high priority tickets on our contract I suppose)

[beldmit]

Hmm... I'm pretty sure this patch was merged into RHEL and Fedora for a while, could you please double check?

[Jakuje]

I am sorry, but I no longer follow all the changes in OpenSSH and I left this up to @beldmit and @cjwatson after reviewing the changes. I thought it made it in. Checking the Fedora repository, it looks like it is already in:

https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-8.0p1-gssapi-keyex.patch#_2624

for some year:

https://src.fedoraproject.org/rpms/openssh/c/9fd6981674fff5cd3a6776939cd2ea2cc1f347cb

and as the comment says, likely also in RHEL 9. RHEL 8 does not have this fix as far as I know.

I can not comment on whats up in Debian/Ubuntu. To ask for the status, using the ubuntu bug tracker where it comes from would be probably best:

https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1938144

Indeed merging the changes and maintaining them in this repository would be something I would prefer instead of having half a dozen of WIP patches and PRs laying around. It is something I am encouraging at least @beldmit to do for some time while doing the Fedora rebases. If @cjwatson is not responsive last years we will have to handle it ourselves. Dima, can you get to make this repository into some shape in coming months? I would be happy to review the PR/changes.

[cellarweasel]

Thank you Jakub and Dmitry (Dima? idk)! This means that the fix is properly pushed but my replication of it in RHEL8 is not a separate issue. The simple work around is to simply do a export KRB5CCNAME=none and then export KRB5CCNAME=/tmp/krb5cc_$(id -u) when one is done with the ssh-ing (or ansible-playbook-ing). Note: in my company we should probably start using keyrings but that is beside this point.
I've written this up for my colleagues and now we have a tenable solution and a fix that we can do nothing but inherit as time goes by.