Consider the following PAM rules for the auth service: auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth required pam_deny.so This works as expected. Now consider the following rules: auth required pam_env.so auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so This also works as expected; if Kerberos is correctly configured, authentication will succeed. But it is undesirable to authenticate system accounts (e.g., root, apache) against Kerberos. We therefore want to select pam_unix authentication for accounts 0 <= uid <= 1000 (our local account range) and 61000 <= uid <= 61999 (our fedora-usermgmt range). We can use pam_succeed_if to do this: auth required pam_env.so auth [default=ignore success=2] pam_succeed_if.so uid <= 1000 quiet auth [default=3 success=ignore] pam_succeed_if.so uid >= 61000 quiet auth [default=2 success=ignore] pam_succeed_if.so uid <= 61999 quiet auth sufficient pam_unix.so nullok try_first_pass auth required pam_deny.so auth sufficient pam_krb5.so use_first_pass auth required pam_deny.so And, indeed, this appears to work: system accounts will hit the pam_unix rule; all other accounts will hit the pam_krb5 rule. However, I've encountered an unexpected failure: when connecting remotely via ssh using keyboard-interactive, sshd unexpectedly dies: 2009-02-05T19:56:24.136406-05:00 example sshd[15644]: pam_krb5[15644]: authentication succeeds for 'joeuser' (joeuser) 2009-02-05T19:56:24.142610-05:00 example sshd[15642]: Accepted keyboard-interactive/pam for joeuser from 10.0.0.3 port 38559 ssh2 2009-02-05T19:56:24.207110-05:00 example sshd[15642]: fatal: PAM: pam_setcred(): The return value should be ignored by PAM dispatch When this happens, the client gets a "Connection reset by peer" error, as the server basically just closes the TCP connection and exits; it doesn't bother to perform an orderly shutdown of the ssh session. This failure occurs ONLY with keyboard-interactive; using "password" or "gssapi-with-mic" authentication works perfectly. The problem is, "keyboard-interactive" is preferred over "password" for virtually all ssh clients. I cannot make any sense of the error message, and I cannot see what (if anything) is wrong with the construct I wrote. Furthermore, I can't find any other service that bombs out with these PAM rules. Are the PAM rules I wrote bogus, or is this a bug in pam (or possibly pam_krb5, or sshd)?
I wouldn't say that it is a bug rather a limitation of the PAM support in sshd. Due to the priviledge separation and the nature of the ssh protocol the pam support in sshd might have some slight problems with some modules. Namely the pam_authenticate is in some authentication methods executed in a different process than pam_setcred, but the pam stack chain should be frozen in pam_setcred. Try this configuration: auth required pam_env.so auth [default=ignore success=3] pam_succeed_if.so uid >= 1000 uid < 61000 quiet auth [default=ignore success=2] pam_succeed_if.so uid > 61999 quiet auth sufficient pam_unix.so nullok try_first_pass auth required pam_deny.so auth sufficient pam_krb5.so try_first_pass auth required pam_deny.so Another possible configuration change which might fix this is to disable priviledge separation in the sshd_config.
Disabling privilege separation in sshd_config had no effect, but your suggested configuration works; both password and keyboard-interactive authentication now work. Thanks much for the suggested config. For anyone else stumbling across this bug, as an additional tip, if you want this "split" authentication to work, you also need to set the following options in sshd_config: # These must all be set to no; PAM will decide whether to use Kerberos # authentication or local authentication. KerberosAuthentication no KerberosOrLocalPasswd no KerberosTicketCleanup no KerberosGetAFSToken no # If the host has a service key, and the user has a TGT in the same realm, this # will enable gssapi-with-mic authentication to login the user without being # prompted for a password. GSSAPIAuthentication yes (Feel free to close this with either NOTABUG or CANTFIX, at your discretion.)