Bug 484322

Summary: valid(?) PAM configuration file causes "fatal: PAM: pamsetcred()" error
Product: [Fedora] Fedora Reporter: James Ralston <ralston>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: mgrepl, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-07 07:42:27 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description James Ralston 2009-02-05 20:21:31 EST
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@EXAMPLE.COM)
2009-02-05T19:56:24.142610-05:00 example sshd[15642]: Accepted keyboard-interactive/pam for joeuser from 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)?
Comment 1 Tomas Mraz 2009-02-06 03:29:30 EST
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.
Comment 2 James Ralston 2009-02-06 16:56:35 EST
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.)