Adding password changing code to openssh

[James F.Hranicky]

I'm currently attempting to add password changing code to openssh. As per my
other posts to this list, I'm doing this for two reasons:

  - getting PAM/Kerberos to work consistently on all platforms is a huge
    pain involving poorly written modules, poorly written PAM implementations,
    and many cores -- not interested. I'll use PAM for authentication only,
    but I want password expiration for XDM, xlock (thanks Ken!), and openssh.

  - I'm not ready to move my whole user base to "true" Kerberized access. As
    long as I have primary services that still require username/password as
    opposed to tickets, I'm not planning on attempting to educate my users
    on using kinit, etc. I would love to move to this, though, when I feel it's
    more feasible.

With that said, here's how I've modified openssh:

	- moved Kerberos auth to the keyboard interactive phase of the login
  	  process. This is where openssh's PAM auth happens, and is the best
	  way (AFAICT) to hold a password changing conversation and print out
	  any banners

	- written a prompter (krb5_prompter_openssh) that is mainly code stolen
	  from krb5_prompter_posix and openssh's PAM implementation.

	- the call to krb5_get_init_creds_password is a follows:

            problem = 
	      krb5_get_init_creds_password(authctxt->krb5_ctx, 
	      				   &creds, authctxt->krb5_user, 
	      				   (char *)password, 
	      				   krb5_prompter_openssh, 
	      				   NULL, 0, NULL, NULL);

The problem: frustratingly, the password-expiration-date-clearing-without-logging-
me-in behavior has returned, this time for real. In other words, once the prompter
is finished collecting the new passwords, the password change "succeeds" according
to krb5_change_password(), but the next call to krb5_get_init_creds() just before
the cleanup label fails in different ways according to the principal's options:

	- with a policy in place that supports password history, *all* new
	  passwords, regardless of previous use, return "Password previously used"

	- with preauthentication set, the preauthentication fails

	- with no options set, I get a decrypt integrity failure

Upon checking the return code (variable: ret) and the code string (variable:
code_string) from krb5_change_password, I get the following:

  (gdb) p ret
  $13 = 0
  (gdb) p code_string
  $14 = {magic = 0, length = 22, data = 0xe3bf0 "Password change failed;\260"}

IOW, the return code indicates the password change succeeded, but the 
code string indicated it did not. Upon trying to log in again, the old
password still works, indicating the change did not really happen, despite
the expiration date being cleared.

Questions: 

	- is the call to krb5_get_init_creds_password() incorrect in any way?

	- does this look like a true bug in the password changing routines, 
	  or have I screwed up something?

This time, one way or another, it does seem that I'm able to clear the expiration
date with a call to krb5_get_init_creds_password(), even if I've made a mistake
in doing so.

My patch is available upon request.

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |
| jfh at cise.ufl.edu                      http://www.cise.ufl.edu/~jfh |
----------------------------------------------------------------------