-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gssapi-keyex failures blocking other authentication methods fallback #20
Comments
|
Heya. Thanks for a detailed reproducer and bug report. I am sorry for a delay, but I am somehow not receiving notifications for new issues in github. At this moment, either @beldmit or @cjwatson could look into that as they are now working on the OpenSSH patches for this so I will probably defer to them. |
|
I think I've got the problem. The request 48 Lines 1886 to 1891 in 8571f49
When we use the Lines 542 to 547 in 8571f49
MONITOR_REQ_GSSCHECKMIC request for trying the other GSS Auth method.
I didn't find the proper place to restore it yet. |
Attempting a connection with kerberos authentication enabled in the server using the following authentication order,
ssh -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex $USER@$HOST -o GSSAPIKeyExchange=yes -o GSSAPIAuthentication=yes,works as expected.
However, if there is no ticket for $USER in the client, the server throws an error:
monitor_read: unpermitted request 48And the client gets the connection closed, instead of receiving an authorization error.
As a consequence, setting additional authentication fallbacks, such as
PreferredAuthentications=gssapi-with-mic,gssapi-keyex,passwordresults in the methods listed aftergssapi-keyexnot being tried at all.Moreover, swapping the authentication order to
gssapi-keyex,gssapi-with-micresults in the described issue not manifesting itself at all. i.e., usingPreferredAuthentications=gssapi-keyex,gssapi-with-mic,passwordwithout a ticket for $USER in the client results in a password being requested.The issue was originally reported against the Ubuntu package https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1938144. However, it is currently reproducible in Debian unstable and in Fedora rawhide.
Reproducers
The reproducer relies on OCI containers.
Before you run the containers, ensure you do have both the server and client scripts in a new directory (to be mounted in the containers). See the next section for getting the proper script for the right distro.
Set up the server container
docker run --rm -it -p 2222:2222 -p 8888:88 -v ${PWD}:/src -w /src $CONTAINER_IMAGE /bin/bashThe $ CONTAINER_IMAGE could be any of
ubuntu:focal,ubuntu:impish,fedora:latest,fedora:rawhide,debian:unstableWithin the server container, run
./reproduce-server.shNote that this script will contain a few interactive bits. You can just press
enter in most of them, do make sure to create (and remember) passwords when prompted for those.
After the server setup is complete (the ssh server will be running), start the
client container setup:
docker run --rm -it -v ${PWD}:/src -w /src ubuntu:focal /bin/bashWithin the client container, run
./reproduce-client.shNote that this script will also contain a few interactive bits.
You should now see the issue reproduced as described above.
Fedora: reproduce-server.sh
Debian/Ubuntu: reproduce-server.sh
reproduce-client.sh
The text was updated successfully, but these errors were encountered: