Background/Behavior is: if you ssh to box via and GSSAPI/Kerberos succeeds and you have a local user in /etc/passwd, you login fine per below PAM config. All Good there.
But if you don't have a local user in /etc/passwd but you can get a host/XXXXXX service ticket (GSSAPI works), sshd fails the login and never get prompts for SecurID (our pam radius points to a SecurID). I understand that. Since the server 'authenticated' the user and pam_unix knows the user is not in /etc/passwd, there's no need to engage any other auth methods.
However, my question is why is it if I first run kdestroy (intentionally have GSSAPI fail), (and still don't exist in /etc/passwd) do I all of a sudden get a Securid prompt (i.e PAM is engaged)?
Running sshd with debug shows: postponed keyboard-interactive for invalid user "user". First, why wouldn't it simply fail? Second why delay? pam_radius is 'requisite', not 'required'.
I would expect to also to simply fail because even though I have not authenticated, I never going to get past pam_unix.
.... ChallengeResponseAuthentication yes GSSAPIAuthentication yes HostbasedAuthentication no KerberosAuthentication no PasswordAuthentication no PubkeyAuthentication yes RhostsRSAAuthentication no RSAAuthentication yes UsePAM yes ....
auth requisite pam_radius_auth.so conf=pam_radius_auth.conf debug retry=3 auth required pam_nologin.so auth required pam_krb5.so.1 account sufficient pam_radius_auth.so conf=pam_radius_auth.conf account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth session required pam_limits.so session optional pam_console.so
auth required pam_env.so auth sufficient pam_krb5.so.1 auth sufficient pam_unix.so auth required pam_deny.so account required pam_unix.so password required pam_cracklib.so retry=3 password sufficient pam_unix.so use_authtok md5 shadow password required pam_deny.so session required pam_limits.so session required pam_unix.so
GSSAPI authentication is not handled by PAM. The PAM module for kerberos is used for password authentication of a user, using the kerberos protocol to obtain a valid ticket.
There are 3 outcomes of the GSSAPI authentication.
If the outcome is 1, the request is denied outright as a token was sent but failed. SSHD does not attempt other authentication methods.
If the outcome is 3,
sshd will next attempt other authentication methods, which includes the PAM
I am not familiar with
pam_radius but I assume it requests an authentication token regardless of whether or not the user exists for security reasons. Having it fail immediately indicates to a user/attacker that such a user does not exist, so from a process of elimination you could enumerate users.
As for the "requisite" option, in the stack setup given "required" and "requisite" have the same affect.
pam_krb can not request a ticket without a valid user anyway so it would end up failing immediately.
For the config given
pam_unix is not used for authentication but authorization, this is a step that occurs after authentication. To clarify; authentication deals with proving you are who you say you are, whilst authorization deals with you having correct permissions to do what you want to do (which in this case is login).
authstack is never consulted by sshd.
sessionwill still be referenced however and can still deny the user. — Feb 13, 2015 at 14:29