Mailing List Archive

http://bugzilla.mindrot.org/show_bug.cgi?id=568





------- Additional Comments From dtucker@zip.com.au 2004-04-06 13:05 -------
It's a lot of code (10 files changed, 805 insertions, 19 modifications).

Could Kerberos password change be adequately support by do_pwchange() in
session.c (possibly with PATH_PASSWD_PROG set to kpasswd or kinit)?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=568





------- Additional Comments From djm@mindrot.org 2004-04-06 13:42 -------
Hang on - non-Kerberos password change is supported because, if one's password
has expired, there is no way to change it unless one is already on the system.

For Kerberos authentication, one must already have Kerberos credentials and thus
be on a system where one change change the password. Why not just run kpasswd
from the local system?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=568





------- Additional Comments From jfh@cise.ufl.edu 2004-04-06 15:30 -------
This patch is for someone logging into a remote system that uses
KerberosAuthentication, so the local system may or may not have
kerberos client programs/libraries.

In the end, it seems that the latest PAM additions have password expiry
working with the modded Cusack module (pam_krb5-1.0.3), so I'm not sure
this patch is needed anymore.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=568





------- Additional Comments From michael.houle@atcoitek.com 2004-04-07 00:37 -------
It is because of PAM that I've tried to get native kerb5 working with
password expiry. Normally I would go with PAM but it seems that I cannnot get
both priv/pub login and interactive login (with password changing) working. Our
relevant pam.conf lines:

sshd auth required /usr/lib/security/pam_krb5.so.1
sshd account required /usr/lib/security/pam_krb5.so.1

Note that we are using Sun's pam_krb5.so.1.

With the above 'account' line enabled, we cannot use pub/priv login. Darren
Tucker explained to me that although PAM's 'auth' is skipped for pub/priv login,
'account' cannot be skipped because you have to check for login times
/etc/nologin etc... If I comment out the 'account' line, pub/priv logins work,
but of course password changing won't work then.

What's happening for pub/priv login is that the 'account' module of pam_krb5 is
trying to check if the password is expired on pub/priv login. This blocks any
automated ssh/scp scripts we have in place.

So it seems we are in a catch-22 and that is why I am interested in this patch.
The native kerb5 support in sshd is working for both modes of operation. I only
need to get password changing working and then I can shutdown telnet ;)

Thanks.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.mindrot.org/show_bug.cgi?id=568





------- Additional Comments From michael.houle@atcoitek.com 2004-04-07 00:44 -------
Clarification:

What's happening for pub/priv login is that the 'account' module of pam_krb5 is
trying to check if the password is expired on pub/priv login. This blocks any
automated ssh/scp scripts we have in place.

The 'account' section needs to ask for the password because it never got it in
the 'auth' section.
The reason is that the 'auth' code was never used in PAM because pub/priv login
is being used, therefore our pam_krb5 is asking for the password in the
'account' section so it can check if it's expired.





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.