openssh bugs - Apr 2004 - [Bug 568] Kerberos password auth/expiry kbdint patch

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





------- Additional Comments From michael.houle at atcoitek.com  2004-04-06 06:04
-------
Can someone please enlighten me on whether this kind of code is going
to be included in the main development ? I thought this would be handled
automatically by the krb5 libraries, so I was suprised to find that password
changing doesn't work in the SSH kerberos implementation. PAM won't work
for
us for similar password change reasons (long story). 

We are using 3.8p1. Will this patch be adjusted to work with 3.8p1 ?

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 dtucker at 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 at 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 at 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 at 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 at 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.