Bug 484322 - valid(?) PAM configuration file causes "fatal: PAM: pamsetcred()" error
valid(?) PAM configuration file causes "fatal: PAM: pamsetcred()" error
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-05 20:21 EST by James Ralston
Modified: 2009-02-07 07:42 EST (History)
2 users (show)

See Also:
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: ---


Attachments (Terms of Use)

  None (edit)
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 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)?
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.)

Note You need to log in before you can comment on or make changes to this bug.