4

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.

Files:

/etc/ssh/sshd_config 

....  
ChallengeResponseAuthentication yes  
GSSAPIAuthentication            yes  
HostbasedAuthentication         no  
KerberosAuthentication          no  
PasswordAuthentication          no  
PubkeyAuthentication            yes  
RhostsRSAAuthentication         no  
RSAAuthentication               yes  
UsePAM                          yes      
....

/etc/pam.d/sshd 

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

/etc/pam.d/system-auth

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
Gravy
  • 770
  • 1
  • 5
  • 17
jouell
  • 601
  • 1
  • 5
  • 20

1 Answers1

4

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.

  1. Authentication failed because credentials were sent but the credentials were invalid.
  2. Authentication succeeded using the credentials presented.
  3. Authentication is ignored because no credentials were supplied.

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 auth section.

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).

Matthew Ife
  • 22,927
  • 2
  • 54
  • 71
  • 1
    Just to make this even more explicit: if GSSAPI or ssh key authentication succeeds, PAM's `auth` stack is never consulted by sshd. `account` and `session` will still be referenced however and can still deny the user. – Andrew B Feb 13 '15 at 14:29
  • @Matthew-Ife: why doesn't sshd doesn't allow other authn attempts for the session if GSSAPI fails? – jouell Feb 13 '15 at 15:31
  • @jouell because you supplied credentials already and they failed. – Matthew Ife Feb 13 '15 at 16:43
  • @Matthew-Ife:Got it. Any idea why that is? sshd allows gssapi-mic after presenting a public key that failed, isn't that a credential? – jouell Feb 13 '15 at 18:47
  • @jouell I believe gssapi is always the first to be attempted, not the other way around. – Matthew Ife Feb 13 '15 at 19:24
  • @Matthew-Ife: You're right. I was just testing now with PreferredAuthentications to see if that's also true w/publickey. – jouell Feb 13 '15 at 21:04
  • @jouell The `ssh_config` manpage lists the default ordering explicitly. – Andrew B Feb 13 '15 at 22:10
  • In my q on Feb 13 at 18:47: Yes, sshd allows gssapi-mic after presenting a public key that failed. That is in line w/Pg 4. of rfc4252: "5.1. Responses to Authentication Requests - If the server rejects the authentication request, it MUST respond with the following: byte SSH_MSG_USERAUTH_FAILURE name-list authentications that can continue". – jouell Feb 17 '15 at 00:46