Ingo Luetkebohle wrote: > S: FTP server ready > C: AUTH PLAIN > S: 534 Request denied for policy reasons. > C: AUTH GSSAPI > S: 335 ADAT=<base64 stuff> > C: ADAT morebase64stuff > S: [loop until security exchange is complete] > > (C is the client, S the server) So what you are saying is that pre-authentication, there is a protocol negotiation phase that includes an exchange that will define the authentication scheme to be used. You are saying that neither PAM nor GSSAPI nor anything 'generic' is involved in this negotiation. Could you explain why 'in principle' a PAM module couldn't handle this sequence? [It looks like some sort of SASL thing, and I remember previously concluding that PAM could support that.] > No, it wouldn't. You assume that PAM can select which of the > mechanisms know to the FTP server is chosen. Well, it can't. It can > only make *itself* be chosen and then do the rest inside the auth > loop. Well, its not exactly pretty, but with a sufficiently cross-referenced pam.d/XXX file, couldn't you have some sort of: auth requisite pam_negotiate.so "FTP server ready" PLAIN GSSAPI auth [default=1 success=IGNORE] pam_switch negotiate_key=GSSAPI auth requisite pam_gss.so auth [default=1 success=IGNORE] pam_switch negotiate_key=PLAIN auth requisite pam_unix.so auth requisite pam_deny.so I'm sure there is something I am not understanding about this issue. In the past, the way protocol negotiations tend to tangle up transport layer encryption protocol and authentication protocol decisions seems to be where the above scheme falls on its face. Is this the problem here? Cheers Andrew
