[OpenAFS] Problem with pam on debian with 1.3.81 kernel 2.6.11

[Douglas E. Engert]

Derek Atkins wrote:
> "Douglas E. Engert" <deengert@anl.gov> writes:
> 
> 
>>There is a gssapimitm.patch for OpenSSH-3.8 that will let it
>>do both if you set: "GSSAPIEnableMITMAttack yes". Its from March 2004.
>>
>>So you can interoperate if you update the old server, or add this
>>patch as a conversion aid and live with the problem for a while.
> 
> 
> Thanks for the pointer.  It turns out that FC3's openssh includes
> this patch but does not build with it.  There's one bug in FC3's
> version of the patch; I had to change one hunk to get it to apply.
> 
> In particular, I needed to add the ' sAcceptEnv,' in the following
> two lines of one of the hunks:
> 
> -	sGssAuthentication, sGssCleanupCreds, sAcceptEnv,
> +	sGssAuthentication, sGssCleanupCreds, sAcceptEnv, sGssEnableMITM,
> 
> With this change the patch applied and I now have FC3 RPMs.
> Unfortuately it appears not to be working properly.  It's not
> acquiring any tickets on the client and it's not proceeding with the
> GSSAPI negotiation.  :(
> 
> debug1: Authentications that can continue: external-keyx,gssapi,password
> debug3: start over, passed a different list external-keyx,gssapi,password
> debug3: preferred gssapi-with-mic,gssapi,publickey,keyboard-interactive,passworddebug3: authmethod_lookup gssapi
> debug3: remaining preferred: publickey,keyboard-interactive,password
> debug3: authmethod_is_enabled gssapi
> debug1: Next authentication method: gssapi
> debug2: we sent a gssapi packet, wait for reply
> debug1: Authentications that can continue: external-keyx,gssapi,password
> debug2: we sent a gssapi packet, wait for reply
> debug1: Authentications that can continue: external-keyx,gssapi,password
> debug2: we did not send a packet, disable method
> debug3: authmethod_lookup password
> debug3: remaining preferred: ,keyboard-interactive,password
> debug3: authmethod_is_enabled password
> debug1: Next authentication method: password
> 
> -derek
> 

Do you have the log on both sides?

These was ambiguity with the early drafts as to how an OID was to be passed,
and I have this additional mod to OpenSSH-3.8 which tries both ways.
But the logit should have written out the Badly formed OID message
to the syslog if this was the problem. Do you see it in the syslog?



--- ,auth2-gss.c        Wed Mar  3 13:21:18 2004
+++ auth2-gss.c Fri Mar  5 14:38:25 2004
@@ -90,7 +90,22 @@
                         gss_test_oid_set_member(&ms, &oid, supported,
                             &present);
                 } else {
+#if 1
+               {
+extern char * client_version_string;
+                       /* should only do for SecureCRT 4.0 */
+                       if (client_version_string) {
+                               logit("Badly formed OID received from %s using %s",
+                               authctxt->user,
+                               client_version_string);
+                       }
+                       oid.elements = doid;
+                       oid.length = len;
+                       gss_test_oid_set_member(&ms, &oid, supported,&present);
+               }
+#else
                         logit("Badly formed OID received");
+#endif
                 }
         } while (mechs > 0 && !present);



-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444