Andy Cobaugh <[email protected]> writes: > Yep, putting exactly those lines in common-account gives 'Connection > close by foo'. I'm fairly certain I tried every combination of requires, > sufficient, etc to the same effect. Only thing that made it work was > putting in a module that returns success always, like pam_permit.
Unfortunately, ssh makes it really hard to debug this. It thinks that your authentication stack has failed at some point in the process, and I'm not sure why that's happening. I'm certain that libpam-krb5 with the default recommended configuration works fine out of the box with GSSAPI on a default Debian lenny system, and there's something peculiar in your environment which is breaking this, since I've run exactly that configuration lots of times and the binaries are the same for everyone. I'm just not sure what it is. > Well, one system was installed with lenny to begin with, and for over a > year we would have to do GSSAPIAuthentication=no to login to it, and the > other 2 systems were upgraded to lenny, which subsequently broke gssapi > logins in the same manner. Putting in pam_permit on all 3 systems fixed > them. pam_permit of course fixes it because it basically disables the entire account stack. Just deleting everything out of the account stack would presumably also fix it. I wonder if pam_krb5 is a red herring here and what's actually failing is pam_unix. Do the accounts you're trying to log in as exist in /etc/shadow? Does it work if you remove pam_krb5 and only keep pam_unix? pam_unix does require all accounts be present in /etc/shadow. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
