There's 3 ways that sshd will force you to change an expired password
when you have PAM enabled (which you do):
1) if you're using keyboard-interactive authentication, sshd will call
pam_chauthtok() as part of the authentication. This should work with
or without privsep.
If you authenticate some other way (eg password), sshd will force you
to change your password once you start your session.
2) if you have privilege separation enabled, by the time your session
starts sshd has dropped the privileges needed to successfully call
pam_chauthtok(). Instead, it'll exec /bin/passwd.
3) if you have privsep disabled, sshd is still running as root and
will call pam_chauthtok().
On Sat, Dec 5, 2015 at 3:23 AM, Nasim, Kam <Kam.Nasim@xxxxxxxxxxxxx> wrote:
[...]
> PROBLEM:
> If I expire a linux user's password (passwd -e <user>) and then log in via ssh, it will prompt you for a password change.
> On changing the password successfully, sshd will drop the connection and client has to reconnect.
That's working as intended, and you should have seen text to that
effect. In session.c (simplified):
static void
do_pwchange(Session *s)
{
fprintf(stderr, "WARNING: Your password has expired.\n");
if (s->ttyfd != -1) {
fprintf(stderr,
"You must change your password now and login again!\n");
execl(_PATH_PASSWD_PROG, "passwd", (char *)NULL);
> If I disable Privilege Seperation ("UsePrivilegeSeperation no") in sshd config then the problem goes away but that opens up a security loophole where the process is running at root privilege even prior to authentication.
RIght, see #3 above.
--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
