Frank Lenaerts
2019-May-10 11:38 UTC
GSSAPIAuthentication globally versus in a Match block
Hi I tried to get GSSAPIAuthentication working in a Match block only (i.e. disabling it at the top level) but didn't succeed. At the top level, I only want allow public key authentication (Password and ChallengeResponse authentication are set to no). I'm using OpenSSH version 7.4. When GSSAPIAuthentication is set to yes at the top level (i.e. not within a Match block), authentication (using the Kerberos ticket I have) works[*]. When it is set to no (the default) at the top level and to yes inside my Match block, it doesn't[**] work. I started sshd in debug mode and noticed the following differences (in both cases, the Match block matches): [*] GSSAPIAuthentication yes at top level debug1: userauth-request for user ... service ssh-connection method gssapi-with-mic [preauth] debug1: attempt 1 failures 0 [preauth] Postponed gssapi-with-mic for ... from ... port ... ssh2 [preauth] debug1: Got no client credentials debug1: ssh_gssapi_k5login_exists: Checking existence of file /tmp/.k5login Authorized to ..., krb5 principal ... (ssh_gssapi_krb5_cmdok) debug1: do_pam_account: called Accepted gssapi-with-mic for ... from ... port ... ssh2 debug1: monitor_child_preauth: ... has been authenticated by privileged process debug1: monitor_read_log: child log fd closed [**] GSSAPIAuthentication no at top level and yes in my Match block debug1: userauth-request for user ... service ssh-connection method gssapi-with-mic [preauth] debug1: attempt 1 failures 0 [preauth] debug1: monitor_read_log: child log fd closed It looks like the "Postponed gssapi-with-mic" path isn't reached in [**]. Anyone have any idea? -- Kind regards Frank Lenaerts SCK?CEN / ICT Group Boeretang 200 B-2400 Mol Belgium Tel.: +3214338723
On Fri, 2019-05-10 at 13:38 +0200, Frank Lenaerts wrote:> Hi > > I tried to get GSSAPIAuthentication working in a Match block only > (i.e. disabling it at the top level) but didn't succeed. At the top > level, I only want allow public key authentication (Password and > ChallengeResponse authentication are set to no). I'm using OpenSSH > version 7.4. > > When GSSAPIAuthentication is set to yes at the top level (i.e. not > within a Match block), authentication (using the Kerberos ticket I > have) works[*]. When it is set to no (the default) at the top level > and to yes inside my Match block, it doesn't[**] work. > > I started sshd in debug mode and noticed the following differences > (in > both cases, the Match block matches): > > [*] GSSAPIAuthentication yes at top level > > debug1: userauth-request for user ... service ssh-connection method > gssapi-with-mic [preauth] > debug1: attempt 1 failures 0 [preauth] > Postponed gssapi-with-mic for ... from ... port ... ssh2 [preauth] > debug1: Got no client credentials > debug1: ssh_gssapi_k5login_exists: Checking existence of file > /tmp/.k5login > Authorized to ..., krb5 principal ... (ssh_gssapi_krb5_cmdok) > debug1: do_pam_account: called > Accepted gssapi-with-mic for ... from ... port ... ssh2 > debug1: monitor_child_preauth: ... has been authenticated by > privileged process > debug1: monitor_read_log: child log fd closed > > [**] GSSAPIAuthentication no at top level and yes in my Match block > > debug1: userauth-request for user ... service ssh-connection method > gssapi-with-mic [preauth] > debug1: attempt 1 failures 0 [preauth] > debug1: monitor_read_log: child log fd closed > > It looks like the "Postponed gssapi-with-mic" path isn't reached in > [**]. > > Anyone have any idea?Hello, This seems like the issue recently fixed in the upstream commit [1]. [1] https://github.com/openssh/openssh-portable/commit/cb24d9fc Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc.