sshd GSSAPIAuthentication broken after 8.0-BETA1 upgrade

From: John Marshall <john.marshall_at_riverwillow.com.au>
Date: Tue, 14 Jul 2009 15:33:57 +1000
Zero interest on -stable after 1 week. Trying -current.

On Wed, 08 Jul 2009, 18:52 +1000, John Marshall wrote:
> I source upgraded a (test) server here (i386) from 7.2-RELEASE-p2 to
> 8.0-BETA1 this morning.  I use GSSAPI as the primary authentication
> method for sshd on that server.  After the upgrade GSSAPI authentication
> stopped working and I can't get enough information to figure out why.
> Perhaps the newer version of Heimdal behaves differently?  Perhaps the
> newer version of sshd behaves differently?
> 
> If I run sshd with debug "-ddd" I see the following:
> 
> debug1: attempt 1 failures 0
> debug2: input_userauth_request: try method gssapi-with-mic
> debug3: mm_request_send entering: type 37
> debug3: mm_request_receive_expect entering: type 38
> debug3: mm_request_receive entering
> debug3: monitor_read: checking request 37
> debug3: mm_request_send entering: type 38
> debug3: mm_request_receive entering
> Postponed gssapi-with-mic for john from 192.0.2.123 port 57225 ssh2
> debug3: mm_request_send entering: type 39
> debug3: mm_request_receive_expect entering: type 40
> debug3: mm_request_receive entering
> debug3: monitor_read: checking request 39
> debug1: Received some client credentials
> debug3: mm_request_send entering: type 40
> debug3: mm_request_receive entering
> debug3: mm_request_send entering: type 43
> debug3: mm_request_receive_expect entering: type 44
> debug3: mm_request_receive entering
> debug3: monitor_read: checking request 43
> debug3: mm_request_send entering: type 44
> debug3: mm_request_receive entering
> GSSAPI MIC check failed
> 
> On the client side (with ssh -vvv) I see:
> 
> debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
> debug3: authmethod_lookup gssapi-with-mic
> debug3: remaining preferred: publickey,keyboard-interactive,password
> debug3: authmethod_is_enabled gssapi-with-mic
> debug1: Next authentication method: gssapi-with-mic
> debug2: we sent a gssapi-with-mic packet, wait for reply
> debug1: Delegating credentials
> debug1: Delegating credentials
> debug1: Authentications that can continue: publickey,gssapi-with-mic,keyboard-interactive
> debug2: we did not send a packet, disable method
> 
> Does anybody know of changes between existing STABLE releases and 8.0
> which would cause this behaviour - and how to accommodate it?  Do any
> strange Kerberos things need to be done as part of the upgrade?
> 
> The client still happily authenticates via GSSAPI to sshd on our other
> 7.2-RELEASE servers.  Subsequent authentication methods succeed on the
> 8.0-BETA1 sshd server, it's just GSSAPI that isn't working.

After fallback authentication (e.g. via keyboard-interactive), I can see
in my credentials cache on the server that a tgt was forwarded from the
client.  If I look in my credentials cache on the client, I can see that
the service ticket for the server was acquired.

Any help on how to get further with troubleshooting this would be
greatly appreciated.

Thank you.

-- 
John Marshall

Received on Tue Jul 14 2009 - 03:34:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:51 UTC